NAS A- TM- 108124 


(NAS A-TM-108124) WORKING NOTES 
FROM THE 1992 AAAI SPRING SYMPOSIUM 
ON PRACTICAL APPROACHES TO 
SCHEDULING AND PLANNING (NASA) 

186 p 


N9 3-18659 
— THRU-- 
N93-18694 
Unci as 


G3/63 0137226 


Working Notes from The 1992 AAAI 

Spring Symposium on 
Practical Approaches to Scheduling and 

Planning 

Mark Drummond 
Sterling Federal Systems 
Mark Fox 

University of Toronto 
Austin Tate 

University of Edinburgh 
Monte Zweben 

NASA Ames Research Center 


I 


i 




Ames Research Center 


al Intelli gence Research Branch 


i 

I 




Report FIA-92-17 


ay, 1992 




1992 Spring Symposium Series 


Practical Approaches to 
Scheduling and Planning 


Working Notes 

(Distribution limited to symposium attendees) 


March 25 - 27, 1992 
Stanford University 


Sponsored by the 

American Association for Artificial Intelligence 




mil 





f 


m ft/*'/ 


wr 


w 


Practical Approaches 
to 

Scheduling and Planning 

Government and industry require practical approaches to a diverse set of 
complex scheduling and planning problems. While scheduling has been stud- 
ied in isolation for many years, recent advances in artificial intelligence, con- 
trol theory, and operations research indicate a renewed interest in this area. 
In addition, the scheduling problem is being defined more generally, and work 
is beginning to consider the closed-loop use of scheduling systems in opera- 
tional contexts. This symposium will serve to bring together theorists and 
practitioners from diverse backgrounds, with the aim of disseminating recent 
results and fostering the development of a cross-discipline understanding. 

The symposium will focus on issues involved in the construction and deploy- 
ment of practical scheduling systems that can deal with resource and time 
limitations. To qualify as “practical”, a system must be implemented and 
tested to some degree on non-trivial problems (ideally, on real-world prob- 
lems). However, a system need not be fully deployed to qualify. Systems that 
j schedule actions in terms of metric time constraints typically represent and 
j reason about an external numeric clock or calendar, and can be contrasted 
\ with those systems that represent time purely symbolically. 

v Issues to be discussed at the symposium include, but are not strictly limited 
to, the following. 

• Integrating planning and scheduling. 

• Integrating symbolic goals and numerical utilities. 

• Managing uncertainty. 

• Incremental rescheduling. 

• Managing limited computation time. 

• Anytime scheduling and planning algorithms, systems. 

• Dependency analysis and schedule reuse. 

• Management of schedule and plan execution. 

• Incorporation of techniques from discrete event control. 
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• Incorporation of techniques from operations research. 

• Learning. 

• Measures of schedule and plan quality. 

• Search techniques. 

• Methodology. 

• Applications. 
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Abstract 

This paper is a progress report on the Spike schedul- 
ing system, developed by the Space Telescope Sci- 
ence Institute for long-term scheduling of Hubble 
Space Telescope observations. Spike is an activity- 
based scheduler which exploits AI techniques for 
constraint representation and for scheduling search. 

The system has been in operational use since shortly 
after HST launch in April 1990. Spike has been 
adopted for several other satellite scheduling prob- 
lems: of particular interest has been the demonstra- 
tion that the Spike framework is sufficiently flexible 
to handle both long-term and short-term scheduling, 
on timescales of years down to minutes or less. We 
describe the recent progress made in scheduling 
search techniques, the lessons learned from early 
HST operations, and the application of Spike to 
other problem domains. We also describe plans for 
the future evolution of the system. 

1 Introduction 

Efficient utilization of expensive space-based observatories 
is an important goal for NASA and the astronomical commu- 
nity: the cost of facilities like Hubble Space Telescope 
(HST) is enormous, and the available observing time is 
much less than the demand from astronomers around the 
world. The Spike scheduling system was developed by the 
Space Telescope Science Institute starting in 1987 to help 
with this problem. The aim of Spike is to allocate observa- 
tions to timescales of days to a week, observing all schedul- 
ing constraints, and maximizing preferences that help ensure 
that observations are made at optimal times. Spike has been 
in use operationally for HST since shortly after the observa- 
tory was launched in April 1990. 

Although developed specifically for HST scheduling. 
Spike was carefully designed to provide a general frame- 
work for similar (activity-based) scheduling problems. In 
particular, the tasks to be scheduled are defined in the system 
in general terms, and no assumptions about the scheduling 
timescale were built in. The mechanisms for describing, 
combining, and propagating temporal and other constraints 
and preferences were designed to be general. The success of 
this approach has been demonstrated by the application of 
Spike to the scheduling of other satellite observatories: 
changes to the system are required only in the specific con- 
straints that apply, and not in the framework itself. 

In the following we first provide a brief description of 
the HST scheduling problem and of the Spike scheduling 
framework. We then discuss some of the experience gained 


with the system since the start of HST flight operations, this 
is followed by a description of the changes required to adapt 
Spike to other satellite scheduling problems. We conclude 
with some comments on the implementation of Spike, and 
on our plans for future work. 

2 Overview of HST Scheduling 

HST scheduling is a large problem: some 10,000 to 30,000 
observations per year must be scheduled, each subject to a 
large number of operational and scientific constraints. Most 
of the operational constraints arise from the low earth orbital 
environment of the telescope. With an orbital period of about 
96 minutes, potential targets are only visible for a portion of 
each orbit before they are occulted by the earth. There are 
constraints due to guide star availability, avoiding the earth’s 
radiation belts, and stray light from the sun, moon, or bright 
earth. There are also constraints arising from thermal and 
power considerations, which tend to restrict the allowable 
attitude of the satellite at different times during the year. Sci- 
entific constraints are specified by astronomers when they 
define the exposures to accomplish their scientific goals. 
These frequently take the form of minimum exposure times, 
temporal relationships among exposures (before, after, 
grouped within some time span, separated by some mini- 
mum and/or maximum interval, etc.). Astronomers may also 
constrain the state of the telescope in other ways, e.g. by 
requiring exposures when HST is in earth shadow (to 
exclude scattered earthlight), by specifying the orientation of 
the telescope, or by configuring one of the six instruments in 
a particular mode. A recent change to the HST ground sys- 
tems now permits the scheduling of two instruments for 
simultaneous operation: this is expected to significantly 
increase the amount of useful data taken by the telescope. 

Because of the design of the telescope and ground sys- 
tem, nearly all HST activities must be scheduled in detail in 
advance. The detailed schedule specifies what commands 
will be executed by the onboard computers, and when com- 
munications contacts will be available for uplinking com- 
mands and downlinking data. Real-time interaction by 
observers is limited essentially to small pointing corrections 
to place targets accurately into the proper instrument aper- 
ture. 

Scheduling HST has been divided into two processes: 
the first is long-term scheduling, which allocates observa- 
tions to week-long time segments over a scheduling period 
of a year or more in duration. This is the responsibility of the 
Spike system. Individual weeks are then scheduled in detail 
by the Science Planning and Scheduling System (SPSS), 
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which orders observations within the week and generates a 
detailed command sequence for the HST control center at 
NASA Goddard Space Flight Center. Further details on HST 
scheduling may be found in [1,2]. 

3 Spike and HST Long-Term Scheduling 

HST observing programs are received at STScI in machine- 
readable form over national and international computer net- 
works. They are then translated by an expert system called 
Transformation [3] into a form suitable for scheduling. The 
Transformation system collects exposures into “scheduling 
units” which are collections of exposures to be executed con- 
tiguously. Transformation makes use of the Spike temporal 
constraint mechanism to collect and propagate temporal con- 
straints: these are made path-consistent and saved in files 
along with the scheduling unit definitions. Spike takes the 
saved scheduling units and derives scheduling constraints 
and preferences for them, based on operational and scientific 
factors such as those described above. Spike then determines 
an allocation of scheduling units to weeks which satisfies all 
hard constraints and as many soft constraints as possible. 
Constraints from different sources are combined using a 
weight-of-evidence mechanism generalized to cover a con- 
tinuous time domain, as described in detail elsewhere [4], 
The result is a set of “suitability functions” which indicates 
goodness over time for each scheduling unit, and also indi- 
cates times when a scheduling unit cannot be scheduled due 
to violations of strict constraints. Most of the HST-specific 
scheduling details go into the definition of the suitability 
functions, which, for long-term scheduling, are defined at a 
high level of abstraction and relatively coarse time granular- 
ity. More details about Spike constraint representation and 
manipulation may be found in [5]. 

Spike treats schedule construction as a constrained opti- 
mization problem and uses a heuristic repair-based schedul- 
ing search technique. An initial guess schedule is 
constructed, which may have temporal or other constraint 
violations as well as resource overloads (in fact, given that 
HST observing time is intentionally oversubscribed by about 
30%, it is known ahead of time that there is no feasible 
schedule that can accommodate all the requested observa- 
tions). Repair heuristics are applied to the initial guess 
schedule until a preestablished level of effort has been 
expended. At that point observations are removed to elimi- 
nate remaining constraint violations, until a feasible sched- 
ule remains. There are several important measures of 
schedule quality employed, including the number of obser- 
vations on the schedule, the total observing time scheduled, 
and the summed degree of preference of the scheduled 
observations. The heuristic repair method is fast, and typi- 
cally many runs are made and the best schedule is adopted as 
a baseline. The Spike algorithm has desirable “anytime” 
characteristics: at any point in the processing after the initial 
guess has been constructed, a feasible schedule can be pro- 
duced simply by removing any remaining activities with 
constraint violations, as described further below. 

The repair heuristics used by Spike are based on a very 
successful neural network architecture developed for Spike 
[6,7] and later refined into a simple symbolic form [8] which 
has made the neural network obsolete. The Spike repair heu- 
ristics make highly effective use of conflict count informa- 


tion, i.e. the number of constraint violations on scheduled 
activities or on potential schedule times. Min-conflicts time 
selection is one such repair heuristic, in which activities are 
moved to times when the number of conflicts is minimized. 
Both theoretical analysis and numerical experiments have 
shown that min-conflicts can be very effective in repairing 
good initial guesses [9]. We have found that further improve- 
ment comes from the use of a max-conflicts activity selec- 
tion heuristic, which selects activities for repair which have 
the largest number of conflicts on their current assigned 
time. Spike permits different constraints to have different 
conflict weights, which can be used to cause the repair of the 
most important constraints first; in practice, however, all 
constraints have so far been given the same weight. Both 
hillclimbing and backtracking repair procedures have been 
tried, but hillclimbing has been shown to be the most cost- 
effective on problems attempted to date. 

The choice of a good initial guess is important for 
repair-based methods, and to this end we have conducted 
experiments on different combinations of variable and value 
selection heuristics to find the “best” combination. Over a 
thousand combinations of heuristics were tried by making 
multiple runs on sample scheduling problems. The adopted 
initial guess heuristic selects most-constrained activities to 
assign first, where the number of min-conflicts times is used 
as the measure of degree of constraint Min-conflict times 
are assigned, with ties broken by maximum preference as 
derived from suitability functions. 

Spike currently uses a rather simple technique to 
remove conflicting activities from an oversubscribed sched- 
ule: activities to be removed are selected based on lower pri- 
ority, higher numbers of conflicts, and lower preference time 
assignments. If there remain gaps when all conflicting activi- 
ties have been deleted, then a simple best-first pass through 
the uns ch eduled activities is used to fill them. This final 
phase of “schedule deconflicting” has been little studied and 
is an area which could benefit from further effort 

Spike provides support for rescheduling in several ways. 
TWo worth mentioning in particular are task locking and 
conflict-cause analysis. Tasks or sets of tasks can be locked 
in place on the schedule, and will thereafter not be consid- 
ered during search or repair (unless of course the user 
unlocks them). These tasks represent fixed points on the 
schedule. Conflict-cause analysis permits the user to force a 
task onto the schedule, then display what constraints are vio- 
lated and by which other tasks. The conflicting tasks can be 
unassigned if desired, either individually or as a group, and 
returned to the pool of unscheduled tasks. This helps with 
the most common rescheduling case, where a specific activ- 
ity must be placed on the schedule, thereby disrupting at 
least some tasks which are already scheduled. A limited 
study of m inima l -chan ge reschedu ling has bee n conducted 
[10], but much more work remains to be done in this area. 

Hillclimbing repair methods like the one used in Spike 
have much in common with simulated annealing techniques 
such as described by Zweben et al.[ll]. One of the open 
research issues is which technique has an advantage on 
which types of problems. 
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4 The Experience of HST Operations 

Shortly after HST was launched it was discovered that the 
telescope main mirror had been figured incorrectly, resulting 
in lower resolution than anticipated. This has not only lim- 
ited the scientific usefulness of HST (although it still remains 
Tar superior to any ground-based telescope), it has also 
greatly disrupted the scheduling process. Observing plans 
made years in advance of launch have had to be revised, 
leading to a shortage of ready-to-schedule observing pro- 
grams and thus reducing the efficiency with which schedules 
could be generated This problem still affects ongoing opera- 
tions, and as a result Spike has only once been used to gener- 
ate a true long-term schedule. Instead, Spike is used 
routinely to identify observations to place in the schedule 
approximately two months into the future. As the character- 
istics of the telescope and instruments have become better 
understood, the pool of observing programs has been grow- 
ing: the second round of open proposal selection will be 
completed in December 1991, and we anticipate that by the 
Spring of 1992 a sufficient pool will exist to permit long- 
range planning as originally expected. NASA is now plan- 
ning a servicing mission to correct the HST optics in early 
1994. 

The most significant lesson learned since launch, how- 
ever, is the impact of high levels of change on the planning 
and scheduling systems. Instead of the anticipated level of 
about 10% of proposals changing, the actual rate of change 
has been closer to 100%. While some of this change is 
clearly attributable to the discovery of HST’s spherical aber- 
ration, many other factors have contributed as well: nearly 
every instrument on the telescope has demonstrated unex- 
pected behavior in one form or another, and each has led to 
revisions in observing plans to compensate. The net effect is 
that change is the norm, not the exception, to the extent that 
stress has been high on the software systems and on the peo- 
ple who operate them. The problem stems from the fact that 
an observing program may consist of many hundreds of 
exposures, which can all be at different stages of the sched- 
uling pipeline. If an observing program is changed, users 
must back up to the beginning of the process for that pro- 
gram, thus work done on the previous version is potentially 
wasted. Alternatively, a new observing program can be cre- 
ated to describe the changed portions of the original erne, but 
then keeping track of active and obsolete portions of the 
original is required. 

If there is any recommendation to be made to develop- 
ers of future systems like those for HST, it is to build in the 
expectation of change from the outset [12]. Even though the 
initial cost will be higher, the operational costs will be signif- 
icantly lower. 

Spike and the other HST ground systems have been 
exercised several times on "targets of opportunity” — pro- 
grams to be scheduled and executed on an crash basis. Turn- 
around has been as short as a few days, which is well within 
the pre-launch expectations. One such target of opportunity 
program took the pictures of the dramatic storm on Saturn in 
December 1990, which were subsequently made into a time- 
lapse movie. 


5 Hierarchical and Short-Term Scheduling 

Spike has been adopted for scheduling three future astro- 
nomical satellite missions: 

• the Extreme Ultraviolet Explorer (EUVE), an ultraviolet 
telescope built and operated by UC Berkeley and God- 
dard Space Flight Center, 

• ASTRO-D, a joint US-Japan X-ray telescope, and 

• XTE, the X-ray timing Explorer (MIT/GSFC) to study 
time-variability of X-ray sources. 

The adaptation of Spike for these problems has led to 
the successful demonstration of the flexibility of the Spike 
scheduling framework. As indicated above. Spike was 
designed so that new tasks and constraints can be defined 
without changing the basic framework. For ASTRO-D and 
XTE, Spike is operated in a hierarchical manner, with long- 
term scheduling first allocating observations to weeks much 
as they are for the HST problem (and with similar types of 
long-term constraints and preferences). Then each week is 
scheduled in detail, subject to the detailed minute-by-minute 
constraints ofTow earth orbit operation. The major changes 
required to implement short-term scheduling were: 

• a new type of task that can have variable duration 
depending on when it is scheduled, and which can be 
interrupted and resumed when targets are occulted by the 
earth or the satellite is in the radiation belts 

• new classes of short-term scheduling constraints which 
more precisely model target occultation, star tracker 
occultation, ground station passes, entry into high radia- 
tion regions, maneuver and setup times between targets, 
etc. 

• an interface between different hierarchical levels, by 
which a long-term schedule constrains times for short- 
term scheduling and conversely 

• a post-processor which examines short-term schedules 
for opportunities to extend task durations and thus utilize 
any remaining small gaps in the schedule to increase effi- 
ciency 

All of the general constraint combination and propaga- 
tion mechanisms, and the schedule search techniques, apply 
directly to both long-term and short-term scheduling. Figure 
1 illustrates the application of Spike to short-term scheduling 
for a sample of X-ray targets such as might be observed by 
ASTRO-D or XTE. Note that several observations are bro- 
ken to fit around occultations and so are taken in multiple 
segments. 

Most of the effort required to apply Spike to the new 
problems was limited to the specific domain modelling nec- 
essary, which typically involves computation related to the 
geometry of the satellite, sun, target, and earth. These prob- 
lems can be expected to differ from one satellite to another, 
and it is not surprising that different models are required. 
Some of the modelling includes state constraints, although 
Spike does not perform explicit planning (see, e.g. [13]). 

EUVE is unusual in that it makes long (2-3 day) obser- 
vations, in contrast to HST, XTE, and ASTRO-D which typi- 
cally make numerous short (15-40 minute) observations. As 
a consequence, EUVE is schedulable over year-long inter- 
vals without breaking the schedule into hierarchical levels. 
One of the more interesting results from a comparison of 
search algorithms for scheduling EUVE was that the Spike 
repair-based methods gained an extra 20 days of observing 
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/.An example of Spike output on short-tom scheduling of astronomical observations. Shown is a 24-hour portion of a 7-day sched- 
ule, The start-time suitability for each exposure is plotted as the upper graph, with interruptions due to target blockage by the earth and by 
satellite passage through high-radiation regions. The available exposure intervals are shown below as open bars, which are filled in to indi- 
cate the actual scheduled times. Some of the observations can be fit within one print; others must be interrupted and thus span several orbits. 


time in a year, when compared to the best incremental sched- 
uling approach. 

6 Spike Implementation 

The implementation of Spike started in early 1987 and was 
initially based on Texas Instruments Explorers as the hard- 
ware and software environment. The Spike graphical user 
interface was implemented in KEE CommonWindows 
(Intellicorps, Inc.), but the remainder of the system (about 
40,000 lines of code) used only Common Lisp and the Fla- 
vors object system. At HST launch, STScI had a complement 
of 8 TI Explorers and microExplorers used for Spike opera- 
tion, development and testing. 

Since the initial development of Spike began there has 
been a great deal of evolution in Lisp hardware and software. 
A significant amount of effort has gone into modifying the 
system to keep current with these changes. In late 1991 we 
are in the process of moving from Explorers to Sun SparcS- 
tation ns as the primary operations and development work- 
station. All of the Flavors code has been automatically 


converted to the Common Lisp Object System. The Lisp 
used on the SparcStation is Allegro Common Lisp from 
Franz Inc. Allegro CL supports a version of CommonWin- 
dows based on X-windows, and so the user interface contin- 
ues operate on Unix platforms as it did on the Explorers. We 
are presently investigating the use of alternative window sys- 
tems, and have prototyped the use of CLX, CLIM, and Motif 
for the user interface (the latter is based on the publicly 
available GIN A/CL M). We expect to see a complete rede- 
sign of the user interface in the next year. Spike can also gen- 
erate high-resolution Postscript versions of schedules and 
constraints; one example of this is shown in Figure 1. 

Updating Spike for new Lisp language features has not 
been difficult. There are, however, plans to remove some fea- 
tures that were developed for Spike which have since 
become part of the language (such as a logical filename 
mechanism). At present there are no plans to convert any of 
the system to C or C++. 
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7 Future Directions 

Several significant enhancements to Spike are planned 
over the next year. One of these, a rewrite of the graphical 
user interface, has already been mentioned above. Another 
enhancement deals with tracking the status of HST observ- 
ing programs and exposures. All scheduled programs pass 
from the proposal entry system through Spike, while feed- 
back on scheduling and execution status is received by Spike 
both from SPSS and from the HST data analysis pipeline. 
This provides information to Spike users which forms the 
basis for rescheduling decisions. We plan to integrate this 
data into a relational database, along with additional infor- 
mation from the HST optical disk data archive, which will 
provide a central source of information on the status of all 
HST observations. 

We are also planning several systematic studies of the 
Spike scheduling search heuristics to see what further 
improvements can be made, either in performance or in qual- 
ity of schedule. These will include the initial guess, repair, 
and deconfiict strategies. We also plan to investigate whether 
the use of short-term scheduling on the HST observations 
can improve the quality of the long-term schedule sent to 
SPSS. There are, however, no plans to have Spike do the 
final short-term scheduling for HST, due to the extreme cost 
of integration with the existing telescope and instrument 
commanding software which generates the command 
sequences for the spacecraft 

8 Conclusions 

The Spike system has performed as planned in the first 18 
months of HST operations. The success of Spike helps dem- 
onstrate the utility of AI technology in NASA flight opera- 
tions projects. The flexibility of Spike has been 
demonstrated by adapting it for several other missions, and 
by integrating long-term and short-term scheduling at differ- 
ent hierarchical levels of abstraction in the same constraint 
representation and scheduling search framework. 
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Introduction 

Many problems in transportation can be represented 
as flow problems, and can be optimally solved us- 
ing efficient linear programming techniques [BHM77] 
[BGAB83]. But in some cases this approach is seri- 
ously oversimplified. IF the problem includes depen- 
dencies between different operations, planning is nec- 
essary. If the system parameters change dynamically, 
the assumptions on which flow models are based be- 
come false, as in the case when the capacity of trans- 
portation facilities can change during the interval be- 
ing analyzed. Finally, if detailed schedules are to be 
produced, answers in terms of bulk quantities do not 
suffice. 

These problems require approaches that combine ca- 
pabilities traditionally associated with planning and 
with scheduling, and that do not require their param- 
eters to remain constant. Historically, temporal plan- 
ners [DFM88J [AK83] have dealt with combining gen- 
eral operators to achieve a set of goals over time but 
have poorly attended to issues related to the optimiza- 
tion of resource usage. On the other hand, schedulers 
[SOP + 90] [Sad9l] have been concerned with allocat- 
ing times and resources to operations in fixed pro- 
cess plans, ignoring questions of goal-oriented prob- 
lem solving. The HSTS temporal planning framework 
[MSCD91J is an attempt to combine the capabilities of 
the two approaches. HSTS has been previously used 
for planning and scheduling the observations for the 
Hubble Space Telescope. HSTS emphasizes the de- 
scription of the problem domain as a dynamical system 
organized through the use of state variables, i.e. per- 
sistent properties of objects in the domain. It also al- 
lows the development of opportunistic planners, where 
constraint posting and temporal inferences are not re- 
stricted to predefined directions on the time horizon 
(as in simulation and temporal projection) but the fo- 
cus of problem solving can concentrate on the most 
congested areas of the time line. 

In this paper we describe preliminary work done in 
the CORTES project [FS90], applying HSTS to a trans- 
portation planning and scheduling domain. First, we 
describe in more detail the transportation problems 
that we are addressing. We then describe the funda- 
mental characteristics of HSTS and we concen trate on 
the representation of multiple capacity resources. We 
continue with a more detailed description of the trans- 


portation planning problem that we have initially ad- 
dressed in HSTS and of its solution. Finally we de- 
scribe future directions for our research. 

The transportation problem 

We are interested in addressing large-scale, complex 
transportation planning and scheduling problems, such 
as are found in disaster relief operations or other large- 
scale, international responses to emergency situations. 
For example, the transportation aspects of military op- 
erational plans (or OPLANs) must be feasible, given 
the allocated transportation resources [Han88]. If not, 
they must be reworked, or have more resources al- 
located to them. OPLANs are very large, involving 
the movement of tens of thousands of individual units, 
which vary immensely in size and composition, from 
a single person or piece of cargo to an entire division. 
However, OPLANs do not explicitly represent justi- 
fications for precedence constraints due to the struc- 
ture of the domain and are therefore difficult to mod- 
ify or adapt to other situations. To concentrate on the 
representation of domain structure in a transportation 
schedule, we addressed the ‘bare base 7 deployment sce- 
nario used at the Armed Forces Staff College (AFSC) 
to train joint planning officers. The goal is to turn a 
bare runway into a fully functioning air base. Doc- 
uments are available from AFSC describing scenario 
assumptions and types of available units, including rec- 
ommended sequencing, and some hints at the depen- 
dencies between units. This domain includes only 92 
unit types, in 40 general categories. It is also simpli- 
fied in that OPLANs generally involve much more than 
deploying a single air base, and more than one armed 
service. 

Our analysis of the bare base domain revealed two 
facts: 

• The domain requires the ability to represent and rea- 
son about aggregate capacity resources. 

• This domain consists primarily of a moderate num- 
ber (order of 10) dependency cycles, each centered 
around a different support function, such as air traf- 
fic control, aircraft refueling, personnel or cargo un- 
loading, etc. The arrival of support units increases 
the possible arrival rate of additional support units. 

We isolated one of the dependency cycles, the refu- 
eling capacity /throughput loop, as an initial ‘atomic 7 
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domain. A demand on the base refueling capac- 
ity, an aggregate resource, can be satisfied by bring- 
ing more refueling units to the base. The arrival of 
a unit permanently increases refueling capacity, which 
in turn affects the rate at which planes can arrive, 
since they use some amount of refueling capacity im- 
mediately after moving. This increases also the rate at 
which additional units can be brought in. These sim- 
plified refueling units have no support requirements, 
so when they are operational at the base they increase 
its capacity, without requiring any other units to be 
brought in. 

The representation and solution of this problem is 
an important step toward a solution of the bare base 
scenario. 

Representing plans in HSTS 

Transportation problems require to be able to deal 
with dependencies involving state and resource capac- 
ity ( e -g-> a unit that requires a plane to move from A 
to B can be allocated space only on a plane that is also 
moving from A to B). This can be done by using the 
HSTS planning and scheduling framework [MSCD91]. 
The two main components of the framework are a do- 
main description language, for modeling the struc- 
ture and dynamics of the physical system at multiple 
levels of abstraction, and a temporal data base, for 
representing possible evolutions of the state of the sys- 
tem over time. 

In this section we describe the basic primitives pro- 
vided by HSTS and the extensions needed to represent 
aggregate resource capacity. 

Representing state 

An HSTS model is subdivided into state variables, 
each of which can assume one and only one value in any 
instant of time. A value has the form R(x 1 , X 2 , . . . , r n ). 
For example, a plane ?p has a location, represented 
by state variable Loc(?p ), that can assume value 
MOVE(?p i ?u y ?src i ?dst) representing the fact that ?p 
is in transporting unit ?u from location ?$rc to location 
?dst. HSTS is interval based, i.e., if a value occurs on a 
state variable, it persists for a continuous non- zero time 
interval. A value can occur under conditions specified 
through a duration specification and a compati- 
bility specification. 

Figure 1 shows a hypothetical value descriptor. The 
duration is expressed as a range constraint, [d,D], 
with d and D representing respectively a lower bound 
and an upper bound function. The rest of the descrip- 
tor specifies the compatibilities that have to be sat- 
isfied. A compatibility specification is an AND/OR 
graph connecting several elementary compatibilities. 
Each compatibility is composed of a temporal rela- 
tion and the specification of a segment of behav- 
ior on a state variable. For example the compat- 
ibility [met-by (i/ } Loc(?p) } AT(?src)}] associated to 
{Loc^p), MOVE(?p i ?u i ?src J ?dst)) in Figure 1 speci- 
fies that in every legal behavior, the value MO VE must 
occur immediately after the value AT on Loc(?p). The 
symbol v is one of two different kind of segments of 
evolution of a state variable: j/, constraining a single 


(£oc(?p), MOVE(?p , ?«, ?src,?dst)) 

duration: [<fur(?snc, ?dst), Dur(?src,?dst)] 
compatibilities: 


AND ( 


met-by {u,Loc{lp),AT(?src))] 

meets (i/, Loc(?p ), REFUEL(? d$t))] 

eql (v, Loc(?u ), MOVE(?p , ?u, ?src, ?dst))]) 


Figure 1: HSTS value descriptor 


value, as in the example above, and <r, for sequence 
compatibilities. A sequence that can be substituted by 
an unspecified number of values occurring on the same 
state variable, all of which must satisfy a constraint 
associated with the sequence. We will see examples 
of sequences when we will discuss aggregate capacity 
state variables. 

Behaviors can be constructed within the HSTS Tem- 
poral Behavior Data Base. The unit of descrip- 
tion of temporal behavior is the token, a quadruple 
( sv , typc.siyCt), where sv is one of the state variables 
in the system model, type is a subset of the state vari- 
able’s possible values, and st and et are the token’s 
start and end times respectively. Tokens represent an 
uninterrupted segment of evolution of a state variable. 
During the planning process a token can be refined 
by being split into any number of component tokens; 
however, a token that has been designated to repre- 
sent the occurrence of a value cannot be further split. 
A token that can be split is referred to as a plan con- 
straint; one that cannot be split is referred to as a 
plan value. The TDB also allows the representa- 
tion of token sequences which implement the occur- 
rence of a sequence specification. Tokens and token 
sequences are connected by a network of constraints: 
temporal constraints, relating the start and end 
times of each token, and type constraints, referring 
to the type of each token. Temporal and type con- 
straints derive either from the expansion of compatibil- 
ities and durations extracted from the model of the sys- 
tem, from requirements directly imposed by the user 
and therefore constituting the problem to be solved, 
or from refinement decisions taken during the prob- 
lem solving process where one of multiple alternatives 
needs to be explored. 

Representing Aggregate Resource 
Capacity 

At the base of the HSTS representation philosophy is 
the assumption that it is possible to identify each state 
variable into which a system model is decomposed and 
that each state variable can assume one of a handful 
of symbolic values. However, this basic mechanism of 
representation can become very cumbersome. For ex- 
ample, to reason on the allocation of available space 
on a plane to materials, we would have to subdivide 
space on the plane into “unit of space” state variables, 
with values ‘free’ or ‘used’, subdivide also the materials 
into units of space, and allocate capacity each unit of 
material space to a unit of plane space. Although this 
might be necessary for a detailed map of the allocation 
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of plane space, it is overly detailed for cases when we 
need only an aggregated characterization of the use of 
space. 

HSTS can represent aggregated capacity as an ag- 
gregate state variable. The value of an aggregate 
state variable at a given time is a summary of the value 
of a corresponding set of atomic state variables at the 
same instant of time. In the transportation planning 
domain, the use of cargo or parking space or the gen- 
eration or use of refueling capacity by a unit or plane 
at a base falls into this category. 

A set of atomic state variables constitutes the con- 
ceptual base on which the aggregation is built. In our 
discussion, they are atomic resources that can be 
used by one and only one operation at a time. An 
operation OP, is the value assumed by the state state 
variable of a job ?j, St(?j), while ?j is undergoing the 
specified operation. If ?j is not undergoing any opera- 
tion, the value of St(?j) is IDLE. An atomic resource ?r 
has a single atomic state variable, St(?r), with possible 
values OPER (processing some operation) and IDLE. 

The occurrence of OP, and of OPER is regulated by 
the following bidirectional compatibility: 

( v , OPi)[eql (i/, St(?r), OPER)] 

If the atomic resources in a pool ?r.p are perfectly 
substitutable, they can be aggregated into a single ag- 
gregate state variable, the aggregate processing ca- 
pacity of the pool, Cap(?r.p). At any instant of time, 
the aggregate state variable will assume a single value 
that will summarize the distribution of values over its 
component state variables at that time. Cap(?r.p) 
gives the number of resources in the pool that hold 
each of the values OPER and IDLE; its values are rep- 
resented as follows: 

{(OPER, m), (IDLE, n 2 )} 

indicating that ni atomic resources in ?r.p are in an 
OPER state and n 2 are in an IDLE state. The number 
of resources in ?r.p at that instant of time is n t + n 2 . 

In general, a value for an aggregate state variable is a 
list of such entries {value, counter). 

Compatibility constraints on values of aggregate 
state variables specify one or more atomic values and, 
for each value, the number of atomic resources affected. 
For example, assuming that OP, requires c, atomic re- 
sources, we will have: 

(Sipi), OPi) — [eql (a, Cap(?r.p), (OPER, INC(+*)), 

(IDLE,INC(-Ci)))] 

This means that whenever OPi occurs, a sequence of 
values must be found on Cap(?r.p), and the start and 
end times of the sequence must coincide with the start 
and end of OP as indicated by the temporal relation 
eql. The type specification describes the local effect of 
the compatibility on each of the values in the sequence, 
i.e, the number of atomic resources that are OPER is 
incremented by +q, while the number of those that 
are IDLE is decremented by c<. 

At time r, the actual value of an aggregate state 
variable can be computed once the set of constraints 
that contain r is known. In the case of Cap(?r.p), if we 
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Figure 2: Posting a sequence constraint on an aggre- 
gate capacity state variable 


suppose we have n^ T entries of type {OPER, INC {a)) 
and n idU entries of type (IDLE, INC(cA), the value 
{{OPER, ni), (IDLE,ri2)} at time r satisfies the rela- 
tions: 

n *pr n idU 

ni = £ c * "2 =J2 e i 

• =1 J=1 

where c $ * and Cj can be both positive (creation) or 
negative (consumption). - • 

During the planning process, the evolution of an ag- 
gregate state variable is represented in the temporal 
data base by a sequence of plan constraints determined 
by the imposition of a set of sequence constraints (Fig- 
ure 2). Note that the temporal extension of each ag- 
gregate state variable’s value is not fixed. This is an 
important difference from other scheduling systems, 
where the times must be fixed if the values of aggregate 
capacities are to be fixed [SOP+90] [Sad9l]. 

Consistency of the state of a temporal data base can 
be checked by temporarily assuming that no more se- 
quence constraints will be posted and, therefore, the 
plan constraints can be safely substituted with plan 
values that can be computed by applying constraints 
like those for ni and i? 2 , above. The data base will 
be inconsistent when an aggregate value contains a 
counter whose value is negative. Notice however that, 
in the case where the physical system allows the gen- 
eration of capacity (as for aggregate processing ca- 
pacity), partial inconsistency can be resolved without 
backtracking by posting additional compatibilities pro- 
viding the missing capacity. 

Planning within HSTS 

The atomic domain was intended to demonstrate that 
the new extensions to HSTS for this type of do- 
main (principally those for handling aggregate capac- 
ity ) function correctly, and provide the necessary prim- 
itives to solve the fundamental problems that such a 
domain presents. 

The atomic domain representation 
The state variables in this domain are the refueling and 
throughput properties of three types of objects: units, 
planes, and bases. 
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Each unit has two associated state variables, its lo- 
cation Loc and its state St. A unit’s Loc can have the 
values AT and MOVE . These correspond to the unit 
being stationed at some base (e.g., home or destina- 
tion) or being in transit. A unit’s St can have the val- 
ues NOT-OPER or OPER. These indicate whether it is 
capable of providing refueling capacity. When OPER , 
it adds enough capacity to refuel one additional plane. 
Each plane has one state variable, Loc , which can have 
the values IDLE, MOVE , and REFUEL. 1 . A base 
has one aggregate state variable, its refueling capac- 
ity iLC, containing distributions of two values, AVAIL 
and USED, indicating the total amount of available 
and used refueling capacity at any time. The principal 
compatibilities describing this problem are: 

• The MOVE of a unit is followed by it being OPER 
some non-zero amount of time later 2 : 

(Loc(?u), MOVE(?p,?u, ?src, ?b)) — 

[*/([*,«]) (v 9 St(?u) t OPER(?u,n))) 

• The MOVE of a unit is concurrent with the MOVE 
of a plane: 

{Loctt%) f MOVE{*p f ?u*m*h)) — 

[eql (v, Loc(?p ), MOVE(lp, ?n t ?snr, ?&))] 

• The MOVE of a plane is immediately followed by 
REFUEL: 

(Loc(?p), MOVE(?p, ?«, ?src, ?6)) 

[meets (u, Loc(?p), REFUEL(?p,?b))] 

• The unit increases R-C(?b) while it is OPER : 

($<(?«), OPER(?u,?b)) — 

[eql (c, R-Cpb), {(AVAIL, INC(+ 1))}] 

• The REFUEL of the plane creates a demand on 
R.C(?b): 

(Loc(?p),REFUEL(?p,?b)) - [eql (<r,R-C(!b), 

{(USED, INC(+1)), (AVAIL, INC(-l))})] 

The atomic domain planner 

The HSTS model of a domain describes domain con- 
straints in terms of durations of and compatibilities 
between values of state variable tokens, as described 
previously. This creates an implicit space of legal sets 
of state variable value sequences, within which any par- 
tial (or complete) solutions to problems in this domain 
must lie. 

However, in order to describe any specific partial 
solution, a particular set of legal choices must be made. 
Many such sets of choices will result in inconsistent sets 
of compatibilities, not corresponding to any possible 
system behaviors. Finding a consistent set of choices 
(i.e., planning) can still be very difficult. Within the 
HSTS least-commitment framework, the final solution 

x For this abstract model, representing refueling state 
and location separately would have introduced irrelevant 
complications. 

2 This is necessary to prevent a degenerate problem, 
where each unit brought in adds enough capacity to han- 
dle its own plane, thus immediately allowing an arbitrary 
number of units to be brought in. 


is a representation of a range of behaviors that can be 
directly simulated, all guaranteed legal. 

In the case of transportation planning and schedul- 
ing, one must select actual units to supply required 
support, and select actual ranges of arrival times for 
these units. This selection is ultimately based on the 
needs of some set of units whose operation at the desti- 
nation directly fulfills external (top-level) goals. These 
top-level units require support of various kinds, and 
their support units in turn require support. Any of 
these units not already at the destination need to be 
transported there. 

Thus, any unit that needs to be transported ulti- 
mately serves a top-level goal through some chain of 
dependencies. This means that the planner can work 
by finding ‘operators’ that satisfy goals, and then other 
‘operators’ that provide these operators’ preconditions 
and fix problems from their postconditions; except 
that, in HSTS, the planner is assigning values to cer- 
tain time intervals of state variables, and using the 
compatibilities between these values and other values 
as ‘preconditions’ and ‘postconditions’. 

The planning goal is represented as a request for a 
large amount of USED refueling capacity during some 
future interval. The posting of the request creates an 
interval of time in which the AVAIL capacity is nega- 
tive. 

The planning process begins with an HSTS fetch 
for intervals where the base refueling capacity is below 
zero, locating the top-level problem. The planner then 
finds which types of values provide the type of capac- 
ity needed, and which state variables can have these 
values. It selects enough instances of these variables 
to satisfy the demand, creates the appropriate value 
tokens for them, and constrains these tokens to occur 
over the required interval. This solves the top-level 
problem. 

Then, for each of these state variables, its token’s 
compatibilities are implemented, that is, constraints 
between the token and other values are enforced, to 
guarantee that this is a legal behavior. Single-unit 
compatibilities are done first, followed by those that 
affect other units. This ordering is important in gen- 
eral, since local constraints may limit the choices avail- 
able to more global ones. This corresponds to classical 
systems having process plans for individual jobs be- 
fore scheduling their operations. Since dependencies 
between different units of the same type are expressed 
through aggregate variables, this ordering is equivalent 
to saying that compatibilities that do not affect aggre- 
gate variables are done first. The set of local compat- 
ibilities in this domain are simply the first three listed 
in the previous subsection. 

Next, the compatibility for the effect of plane refuel- 
ing on the aggregate capacity is implemented. This 
requires the choice of a particular time interval for 
plane refueling, relative to the intervals of different lev- 
els of aggregate capacity. This is done in one of three 
modes: planes are allocated times as late as possible, 
as early as possible, or at user-selected times. This 
variability demonstrates the complete flexibility of the 
order of decisions in ‘simulated time’ (time in the mod- 
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eled domain). This flexibility allows for opportunis- 
tic decision-making, where decisions are made in the 
most efficient order, not in any pre-determined tempo- 
ral order. Other temporal planners generally cannot 
make decisions this flexibly when working at the most 
detailed level. 

Finally, the effect of the unit becoming operational 
on the aggregate capacity is implemented. In both of 
these last two steps, some search may be needed. The 
interval initially chosen may not produce a legal con- 
figuration, due to the simple mechanism for picking 
an interval and a limitation of the current aggregate 
variable mechanism. Currently, once the contribution 
from a state variable to an aggregate variable is calcu- 
lated, its relative position in the aggregate cannot be 
changed without backtracking. This violates the least- 
commitment principle, and leads to problems: some 
intervals on the aggregate variable have zero length. If 
our simple interval selection rule selects a zero-length 
interval for a non-zero length event, an inconsistency 
results. Currently the easiest way to handle this is 
to implement, detect the inconsistency, and backtrack. 
Very limited search is needed, since non-zero intervals 
are much more frequent. Fixing this failure of least- 
commitment is high on our research agenda. 

When these steps have been carried out for the nec- 
essary number of variables, a complete and consistent 
behavior has been described that fulfills the top-level 
goals. 

Conclusion 

Temporal planning methodologies cam be applied to 
solve transportation planning problems that are be- 
yond the scope of traditional linear programming tech- 
niques. In our work we have addressed one such 
problem and identified a fundamental type of depen- 
dency among its entities. We have then demonstrated 
that problems involving this kind of dependency can 
be solved within the HSTS temporal planning and 
scheduling framework. To solve the full bare base de- 
ployment scenario, we need to extend our current prob- 
lem solver to incorporate heuristic knowledge in order 
to select the most appropriate units and time intervals 
for values, and carry out local search if necessary. 

In order to deal with real-world scale problems, 
it will be necessary to develop further problem ag- 
gregation and abstraction techniques. One promis- 
ing direction concentrates on taking advantage of the 
temporal flexibility of the HSTS framework by com- 
bining least-commitment constraint posting method- 
ologies with probabilistic estimates of resource usage 
[MS87J: the goal is to avoid spelling out unnecessary 
details whenever possible while insuring high quality 
possible executions of the temporal plan. 
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Introduction 

The SES is a facility which houses the software and 
hardware for a variety of simulation systems. The sim- 
ulators include the Autonomous Remote Manipulator, 
the Manned Maneuvering Unit, Orbiter/Space Station 
docking, and shuttle entry and landing. The SES sim- 
ulators are used by various groups throughout NASA. 
For example, astronauts use the SES to practice ma- 
neuvers with the shuttle equipment; programmers use 
the SES to test flight software; and engineers use the 
SES for design and analysis studies. 

Due to its high demand, the SES is busy twenty- 
four hours a day and seven days a week. Scheduling 
the facility is a problem that is constantly growing and 
changing with the addition of new equipment. Cur- 
rently a number of small independent programs have 
been developed to help solve the problem, but the long- 
term answer lies in finding a flexible, integrated system 
that provides the user with the ability to create, opti- 
mize, and edit the schedule. 

COMPASS is an interactive and highly flexible 
scheduling system. However, until recently COMPASS 
did not provide any optimization features. This paper 
describes the simulated annealing extension to COM- 
PASS. It now allows the user to interleave schedule 
creation, revision and optimization. This practical ap- 
proach was necessary in order to satisfy the operational 
requirements of the SES. . i 

Statement of Problem 

The SES facility is scheduled a week at a time. A work 
week consists of seven days, each of which is divided 
into six 4-hour "sessions.” Each session has two sides, 
side-a and side-b. This allows two people to work in 
the facility at the same time. Each person requiring 
time at the facility makes a request telling what equip- 
ment is needed for the simulation. A request consists 
of the required simulators, the preferred days and ses- 
sions, and optionally, a preferred side. Each person 
may make one or more requests per week and may ask 
for multiple iterations of the same request. The SES 
scheduler satisfies their requests by creating a sched- 
ule based on priorities. The SES manager determines 


the priority of each request by the type of work being 
done and the number of repetitions requested. For ex- 
ample, mission related activities have a higher priroity 
than software development activities. And the fourth 
repetition of a request typically has a much lower pri- 
ority than the first. Each week there are about 60 - 
70 requests and 76 session slots to be filled. There are 
additional requests at the last minute for empty slots, 
as well as high priority requests coming through that 
may bump lower priority items. 

There are a few guidelines by which the SES fa- 
cility is scheduled. First, there is only one instance 
of each simulator; therefore the persons working on 
side-a and side-b must use mutually exclusive sets of 
equipment. Second, certain pieces of equipment re- 
side only on certain sides; therefore side assignments 
must coincide with equipment requirements. Third, a 
person may state a preference for particular sessions, 
may state which sessions are acceptable, and may state 
which sessions are unacceptable. The schedule should 
try to accommodate the preferences, but can place the 
person in an acceptable session when the preferred ses- 
sions are not available. Under no circumstance should 
a person be placed in a session which has been marked 
as unacceptable. Fourth, a person can only work up 
to two sessions in one day, and if they do, the sessions 
should be consecutive so that a straight eight hour day 
is worked. Fifth, each person should have at least an 
eight hour break between non-consecutive scheduled 
sessions. Sixth, if a person works more than one third 
shift (session five or session six) then the third shift 
sessions worked should be on consecutive days or at 
least two days apart. 

Each request has a primary and secondary requestor. 
The above rules must be satisfied in the event that 
either the primary or secondary requestor work the 
session. 

There are two goals to consider when scheduling the 
SES facility. One is to produce a weekly schedule in 
which the largest number of requests are satisfied. The 
other is to fill the schedule with the highest priority 
items. These two goals must be satisfied simultane- 
ously, but there are no rules defining the trade-offs be- 
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tween quantity and priority. It is left up to the sched- 
uler to produce a schedule which, in his opinion, works 
the best. In fact, if so inclined, the scheduler may actu- 
ally violate resource or timing constraints listed above 
when producing the schedule. 

Currently, the requests are entered on a PC and then 
transferred to a Cyber computer where an optimiza- 
tion routine written in FORTRAN finds 10 candidate 
schedules. The SES manager then selects one of the 
10 schedules and hand edits it. The editing usually 
consists of adding late assignments and moving assign- 
ments around for subjective reasons. This is done with 
paper and pencil to keep track of resource assignments. 
Finally the handwritten schedule is entered into a PC, 
using a drawing program, where it is printed out for 
distribution. 

When providing an integrated solution for the SES 
problem, all phases of the scheduling process must be 
considered. First, the scheduling system must be able 
to accept and handle all of the constraints and pref- 
erences described by the requests. Second, the system 
must provide the SES manager with an initial feasible 
schedule which is at least as “go°<T as the initial sched- 
ules produced by the FORTRAN program. Third, the 
system must allow the schedule to be modified, even if 
it means overriding constraints. And fourth, the sys- 
tem must print the schedule in the prescribed SES for- 
mat. 

Background 

An interactive scheduling system allows the user to 
impose subjective constraints such as the trade-off be- 
tween the quantity of requests satsified and the prior- 
ities of the activities scheduled. A non-chronological 
system allows the user to place activities anywhere in 
the week, so that high priority items can be scattered 
throughout the week and low priority items can fill the 
leftover time slots. These two characateristics, along 
with the fact that COMPASS only produces feasible 
schedules, lay the ground work for solving the SES 
scheduling problem. The significance of these char- 
acteristics is described further. 

An interactive scheduling system provides an envi- 
ronment where a mixed initiative is possible; that is, 
it lets the computer do what it does best (check con- 
straints and calculate feasible intervals) and lets the 
human do what he/she does best (provide heuristic and 
subjective inputs into the schedule). Together the two 
can cooperatively produce a schedule which reflects 
both the hard constraints and subjective preferences. 
Subjective preferences may be controlled through in- 
put from the user. The input may reflect scheduling 
heuristics, such as the order in which to schedule the 
activities and whether to schedule as soon as possible 
or as late as possible. The input may reflect the de- 
sired look of the schedule, such as choosing where to 
place the activity from among the feasible intervals of 
time. Or the user may interactively direct the search, 


by specifying which items to freeze and which items to 
optimize. 

In contrast, a fully automated system requires that 
all data be completely loaded before the system begins 
scheduling. All rules about scheduling preferences and 
optimization must be coded into the system before the 
scheduling process begins. The system then runs unin- 
terrupted until it finds one solution (or many depend- 
ing on the system) and then presents its findings as the 
finaj schedule. There is generally no effective way of 
editing the schedule once the solution is found. This 
method of scheduling is perfectly acceptable when the 
problem is bounded and the domain can be described 
completely. However, in a highly subjective scheduling 
domain, coding all of the rules (and exceptions-to-the 
rules) may become very laborious or even impossible. 

A non-chronological scheduler allows the system to 
place activities anywhere on the timeline. The sys- 
tem has an omniscient view of time and can determine 
all the feasible intervals of time where the next activ- 
ity may be placed. As each activity is placed on the 
schedule, constraints created by that activity must be 
propagated (either in the environment or directly to 
other activities). When new activities are placed on 
the schedule, they are constrained by the activities al- 
ready on the schedule. A benefit of non-chronological 
scheduling is that high priority items may be placed 
on the schedule first and guaranteed that they be com- 
pleted. Then the schedule may be filled with the lower 
priority items. 

In contrast, a simulation-based scheduler starts at 
the beginning time of the schedule and as it pro- 
gresses through time, it places activities on the sched- 
ule. When resources become available, the system has 
a choice about which item to place next on the sched- 
ule. Once the schedule reaches the ending time, the 
schedule can be evaluated and another pass may be 
made, perhaps making different choices about what to 
place at each decision point. Historically, simulation- 
based schedulers are very popular in the job shop arena 
as they naturally model the behavior of plant opera- 
tions. 

COMPASS, with its simulated annealing extension, 
searches only the feasible solution space. Some sched- 
ulers only search the feasible solution space, while 
others search both the feasible and infeasible solution 
space. It may be substantially easier to find good so- 
lutions if the scheduler is allowed to wander through 
the infeasible solution space. However, allowing in- 
feasible solutions also greatly increases the size of the 
search space. There are far more infeasible solutions 
than feasible solutions. By prohibiting the search of 
the infeasible solution space, the scheduler has more 
time to spend evaluating feasible solutions. Deciding 
which solution space to search depends on the optimiz- 
ing algorithm. 
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Approach 

This section describes how the simulated annealing 
routine is used in conjunction with COMPASS. 

Given a group of selected activities to optimize, the 
simulated annealing algorithm calls upon the COM- 
PASS scheduling engine to unschedule then reschedule 
the selected activities in a different order. The ac- 
tivities are continuously rescheduled and the objective 
function is evaluated for each new schedule until a user 
specified time limit is up. When time is up COMPASS 
displays the schedule with the best score. 

The user designates the focus of attention for the op- 
timization by selecting a subset of activities. The user 
can select all of the activities, in which case the en- 
tire schedule is optimized with respect to the objective 
function. Or the user may select a subset of activities, 
in which case only part of the schedule is optimized. A 
benefit of this is that the user can selectively optimize 
parts of the schedule which need improvement, leaving 
the rest of the schedule intact. 

The user may also specify the amount of time in 
which to run the simulated annealing algorithm. For 
simple schedules or small subsets of activities a small 
amount of time may be all that is necessary. COM- 
PASS displays each new try as it is created. The user 
can actually sit and watch as the schedule is being 
modified. Once time is up, COMPASS redisplays the 
best schedule. 

A scenario for using COMPASS and its simulated 
annealing extension is as follows. A first cut at the 
schedule can be created using the optimization func- 
tion. The user can edit the schedule by unscheduling 
some zctwitits or by forcing unscheduled high priority 
activities (overriding any constraints) onto the sched- 
ule. By evaluating the schedule, COMPASS will dis- 
play all activities which now have conflicts. The user 
can unschedule the conflicting activities and resched- 
ule them (using the optimization function or by plac- 
ing each down interactively). The interaction between 
user placement and optimization continues until the 
final schedule is reached. 

Implementation 

Simulated annealing is an optimization technique 
which combines gradient descent with randomness to 
find global optima. The process used to control the 
optimization is analogous to the annealing of metal; 
hence the name simulated annealing. The annealing 
process is based on the laws of thermodynamics which 
state that atoms tend toward a minimum energy state. 

A metal is annealed by raising the metal to tempera- 
ture over its melting point and then gradually cooling 
it. At high temperatures the atoms are in a high en- 
ergy state, violently and randomly moving about. As 
the metal cools, lower and lower energy states become 
increasingly likely. By cooling the metal slowly, the 
lowest possible energy state, the global minimum, can 
be achieved. 


Simulated annealing is used to find global minima in 
optimization problems in the following fashion. An ini- 
tial solution to the optimization problem is found by 
some means. The search space of solutions becomes 
the state space of the simulated annealing algorithm. 
An objective function, for which a global minimum is 
to be found, is defined over the search solution space. 
The objective function corresponds to the energy func- 
tion. For each iteration, a random change is made to 
the state to obtain a new state. If this new state has 
a lower energy than the previous state, the new state 
is kept. If the new state has a higher energy than the 
old state, it is kept with a probability that varies with 
the simulated temperature. Continuing the analogy to 
the annealing of metal, this probability is proportional 
to the exponential of -c/kT, where c is the change in 
the energy level, k is constant analogous to the Boltz- 
mann’s constant for physical systems, and T is the 
simulated temperature. At very high temperatures, 
most changes in state are accepted, and the result ap- 
proaches a random walk through the solution space. 
At very low temperatures, the probability of accepting 
a change that increases the total energy vanishes, and 
the random walk is limited to changes which decrease 
the total energy. This results in a gradient descent to 
the local minima. To achieve the global minimum, the 
temperature is started off very high and gradually re- 
duced. For each local minimum there is a temperature 
which will allow the random walk to escape the local 
minimum, but not the global minimum. 

In order to apply this algorithm to the SES optimiza- 
tion problem, the following have to be defined: (1) the 
state space of searched solutions, (2) the energy or ob- 
jective function to be minimized, (3) the method for 
calculating the initial solution, (4) the method for ran- 
domly changing from one state to the next, and (5) the 
temperature decay algorithm. 

The solution space consists of all feasible schedules. 

A feasible schedule is one that satisfies all the con- 
straints. The constraints that are applicable to the 
SES scheduling problem are the resource availability 
constraints, the temporal constraints, and the rules 
discussed in the Statement of Problem section of this 
paper. 

The objective function is the negative of the sum of 
the values of the scheduled activities. (The negative 
is used so that minimization of the objective function 
indicates improving schedules.) The value for each ac- 
tivity is derived from the priority input field of the 
schedule request. The priority is an integer between 
I and 22 inclusive, with 1 being the highest priority 
(most important). The value for the activity is set to 
23 minus the request priority. Thus increasing value 
means increasing importance of the task. 

An initial solution is found using a first fit decreas- 
ing algorithm. The activities to be scheduled are 
sorted into decreasing value order. The sorted activ- 
ities are then scheduled using a front loading, or first 
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fit, scheduling algorithm. 

Once a feasible schedule is found, a new random 
schedule is calculated in the following fashion. First, 
the probability that a scheduled task should be re- 
moved is calculated, based upon the current simulated 
temperature. The probability of removal is calculated 
using an equation of the form of the Boltzmann equa- 
tion described above. Thus the probability of removal 
is higher at high temperatures than it is at low tem- 
peratures. This has the effect of allowing larger state 
changes at high temperatures and minor changes at 
low temperatures. 

Next, each activity is examined in decreasing value 
order. If the activity is already scheduled, and a ran- 
domly generated number is less than the probability of 
removal, the activity is removed from the schedule. If 
the examined activity is previously unscheduled, and 
a randomly generated number is less than a constant 
probability of placement, the activity is placed on a 
list of activities to be scheduled. 

Once the entire activity list is examined, with some 
of the activities randomly selected and unscheduled, 
the list of activities to be scheduled is examined. For 
each activity, the program first tries to schedule the 
activity in one of the preferred sessions. If that fails 
(the activity is not scheduled), the program attempts 
to schedule the activity in any one of the acceptable 
sessions. 

Once the new schedule has been created, the energy 
value for this new schedule is calculated. If the new 
energy value is lower than the current energy, the new 
schedule is kept since it reflects an improved schedule. 

If the new energy is greater than the current energy 
(reflecting a poorer schedule), the probability of ac- 
cepting this schedule is calculated using the Boltzmann 
equation described above. 

Finally, the temperature decay used is a simple in- 
verse linear function. The simulated temperature is set 
according to the equation T = TO / (1 + t), where T is 
the current temperature, TO is the initial temperature, 
and t is the simulated time. 

Conclusions 

The simulated annealing algorithm has been success- 
fully implemented and integrated into the COMPASS 
architecture. This new addition allows the user to au- 
tomatically, as well as interactively, create schedules. 
This combination of automatic and interactive capabil- 
ities provides the user with greater functionality and 
control over the development of the schedule. The user 
can define the level of interaction/automation neces- 
sary in order to produce the best schedule. 

The user selects the activities that are to be opti- 
mized. The user may optimize the whole schedule by 
selecting all of the activities or part of the schedule by 
selecting a subset of the activities. (In the SES prob- 
lem the objective function is based on the priorities of 
the activities, so it is feasible to apply it to subsets 


of activities as well as the entire set.) The previously 
scheduled activities that have not been selected remain «*■ 
frozen on the schedule. This is especially beneficial in • 
rescheduling once the initial schedule is underway and 
an event occurs which requires parts of the schedule to m 
be reworked. m 

The SES scheduling problem requires an integrated * 
system which will create an initial feasible schedule, al- 
low the user to alter or optimize parts of the schedule, HI 

and will print out the schedule in the desired format. I 

COMPASS now provides all of these capabilities in one 
cohesive package. The user can schedule both interac- = 

tivly and automatically. The user can override any 5 

constraints by forcing an activity onto the schedule ^ 

at a specific time. The user can validate the sched- 
ule using existing evaluation functionalities. And the = 
user can print out reports in the desired format using S 
PostScript. 
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Introduction 



^The generation of executable schedules for space-based 
observatories is a challenging class of problems for the 
planning and scheduling community. Existing and 
planned space-based observatories vary in structure 
and nature, from very complex and general purpose, 
like the Hubble Space Telescope (HST), to small and 
targeted to a specific scientific program, like the Sub- 
millimeter Wave Astronomy Satellite (SWAS). How- 
ever the fact that they share several classes of operating 
constraints (periodic loss of target visibility, limited on- 
board resources, like battery charge and data storage, 
etc.) suggests the possibility of a common approach. 

The complexity of the problem stems from two sources. 
First, they display the difficulty of classical scheduling 
problems: optimization of objectives relating to overall 
system performance (e.g., maximizing return of science 
data), while satisfying all constraints imposed by the 
observation programs (e.g., precedence and temporal 
separation among observations) and by the limitations 
on the availability of capacity (e.g., observations re- 
quiring different targets cannot be executed simultane- 
ously). Second, a safe mission operation requires the 
detailed description of all the transitions and interme- 
diate states that support the achievement of observing 
goals and are consistent with an accurate description 
of the dynamics of the observatory; this constitutes a 
classical planning problem. 

Another characteristic of the problem is its large 
scale. The size of the pool of observations to be per- 
formed on a yeariy horizon can typically range from 
thousands to even tens of thousands, and, for large 
observatories, the dynamics of system operations in- 
volves several tens of interacting system components. 

To effectively deal with problems of this size, it is es- 
sential to employ problem and model decomposition ^ 
techniques. In certain cases, this requires the ability 
to represent and exploit the available static structure of 
the problem (e.g., interacting system components); in 
other cases, where an explicit structure is not immedi- 
ately evident (e.g., interaction among largejiumbers of \ 
temporal and capacity constraints), the problem solver 
should be able to dynamically focus on different parts 
of the problem, exploiting the structure that emerges 
during the problem solving process itself. 



ft In this paper, we discuss issues of problem and model 

decomposition within the HSTS scheduling framework. / 


HSTS was developed and originally applied in the con- 
text of the HST scheduling problem, motivated by the 
limitations of the current solution and, more generally, 
the insufficiency of classical planning and scheduling 
approaches in this problem context. We first summa- 
rize the salient architectural characteristics of HSTS 
and their relationship to previous scheduling and AI 
planning research. Then, we describe some key prob- 
lem decomposition techniques supported by HSTS and 
underlying our integrated planning and scheduling ap- 
proach, and discuss the leverage they provide in solving 
space-based observatory scheduling problems. - 

Planning and scheduling for 
space-based observatories 

The management of the scientific operations of the 
Hubble Space Telescope is a formidable task; its solu- 
tion is the unique concern of an entire organization, the 
Space Telescope Science Institute (STScI). The work of 
several hundred people is supported by several software 
tools, organized in the Science Operations Ground Sys- 
tem (SOGS). At the heart of SOGS is a FORTRAN- 
based software scheduling system, SPSS, originally en- 
visioned as a tool which would take astronomer viewing 
programs for a yearly period as input and produce ex- 
ecutable spacecraft instructions as output. SPSS has 
had a somewhat checkered history [Wal89], due in part 
to the complexity of the scheduling problem and in part 
to the difficulty of developing a solution via traditional 
software engineering practices and conventional pro- 
gramming languages. To confront the computational 
problems of SPSS, STScI has developed a separate, 
knowledge-based tool for long term scheduling called 
SPIKE [Joh90]. SPIKE accepts programs approved 
for execution in the current year and partitions obser- 
vations into weekly time buckets, each of which can 
then be treated as a smaller, more tractable, short 
term scheduling problem. Detailed weekly schedules 
are generated through the efforts of a sizable group of 
operations astronomers, who interactively utilize SPSS 
to place observations on the time line. 

In the HSTS project we have addressed the short 
term problem in the HST domain, efficiently gener- 
ating detailed schedules that account for the major 
telescope’s operational constraints and domain opti- 
mization objectives. The basic assumption is to treat 
resource allocation (scheduling) and auxiliary task ex- 


15 


pansion (planning) as complementary aspects of a 
more general process of constructing behaviors of a dy- 
namical system [Mus90]. 

Two basic mechanisms provide the basis of the HSTS 
approach: 

1. a domain description language for modeling the 
structure and dynamics of the physical system at 
multiple levels of abstraction, 

2. a temporal data base for representing possible evolu- 
tions of the state of the system over time (i.e. sched- 
ules). 

The natural approach to problem solving in HSTS 
is an iterative posting of constraints extracted either 
from the external goals or from the description of the 
system dynamics; consistency is tested through con- 
straint propagation. For more details, see [MSCD91], 
Three key characteristics distinguish the HSTS 
framework from other approaches: 

1. the explicit decomposition of the state of the mod- 
eled system into a finite set of “state variables” 
evolving over continuous time. This enables the 
development of scheduling algorithms that exploit 
problem decomposability and provides the necessary 
structure for optimizing resource utilization. 

2. the flexibility along both temporal and state value 
dimensions that is permitted by the temporal data 
base (e.g., the time of occurrence of each event does 
not need to be fixed but can float according to the 
temporal constraints imposed on the event by the 
process of goal expansion). This flexibility con- 
tributes directly to scheduling efficiency, since over- 
commitment (and hence the greater possibility of the 
subsequent need to backtrack) can be avoided. 

3. the flexibility of the constraint posting paradigm 
to accommodate a range of problem solving strate- 
gies (e.g., forward simulation, back chaining, etc.). 
This allows the incorporation of algorithms that op- 
portunistically exploit problem structure to consis- 
tently direct problem solving toward the most criti- 
cal tradeoffs that need to be made. 

The importance of integrating these three features 
within a single framework can be appreciated by con- 
sidering the limitations of other approaches that ad- 
dress them separately or partially. 

Planning research has focused on the problem of 
“compiling” activity networks that bring about de- 
sired goal states from more basic representations of 
the effects of actions in the world. In contrast to 
HSTS, however, the modeling assumptions of most ap- 
proaches [FHN72, Wil88] do not support explicit repre- 
sentation of temporal constraints depending on contin- 
uous time (e.g., task duration, temporal separation be- 
tween events), and representation of the world state is 
not structured into state variables. More recent plan- 
ning frameworks have only partially addressed these 
issues [Lan88, DFM88, Ver83]. Furthermore, in most 
cases, these frameworks have placed fairly rigid con- 
straints on the manner in which solutions are developed 
(e.g., strict reliance on top down goal refinement with 
forward simulation [DFM88]), preventing an adequate 


consideration of efficient resource allocation over time, 
an issue of fundamental importance in the space-based 
observatory scheduling domain. 

The monitoring of state variables over continuous 
time has alwaysdbeen at the core of scheduling research 
[Bak74]. Operations research has produced optimal 
solutions for very simple scheduling problems [Gra81, 
BS90] or has focused on the definition of dispatch pri- 
ority rules [PI77] for more realistic problems. More re- 
cent research in constraint-based scheduling [SOM* f 90, 
Sad9l], has demonstrated the advantages of dynami- 
cally focusing decision-making on the most critical de- 
cisions first. HSTS differs from other scheduling ap- 
proaches in its temporal flexibility and in its ability to 
dynamically expand auxiliary goals and activities. 

Issues in Integrating Planning and 
Scheduling 

We now highlight some aspects of our approach that 
support the development of solutions for large scale 
scheduling problems in complex dynamical domains 
and, in particular, their relevance to space- based ob- 
servatory domains. 

Use of Abstraction 

The use of abstract models has long been exploited 
as a device for managing the combinatorics of plan- 
ning and scheduling. In HSTS, where models are ex- 
pressed in terms of the interacting state variables of 
different components of the physical system and its op- 
erating environment, an abstract model is one which 
summarizes system dynamics in terms of more aggre- 
gate structural components or selectively simplifies the 
represented system dynamics through omission of one 
or more component state variables. Given the struc- 
ture of space-based observatory scheduling problems, 
the use of an abstract model provides a natural basis 
for isolating overall optimization concerns, and thus 
providing global guidance in the development of de- 
tailed, executable schedules. In the case of the HST, a 
two-level model has proved sufficient. At the abstract 
level, telescope dynamics is summarized in terms of a 
single state variable, indicating, at any point in time, 
whether the telescope (as a whole) is taking a picture, 
undergoing reconfiguration, or sitting idle. The dura- 
tion constraints associated with reconfiguration at this 
level are temporal estimates of the time required by 
the complex of actual reconfiguration activities implied 
by the detailed model (e.g., instrument warmup and 
cooldown, data communication, telescope repointing). 
Execution of an observation at the abstract level re- 
quires only satisfaction of this abstract reconfiguration 
constraint, target visibility (a non-controllable state 
variable accessible to both the abstract and detailed 
models), and any user specified temporal constraints. 
Thus, the description at the abstract level looks much 
like a classically formulated scheduling problem: a set 
of user requests that must be sequenced on a single 
resource subject to specified constraints and allocation 
objectives. 

Planning relative to a full detailed level is neces- 
sary to ensure the viability of any sequencing decisions 
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made at the abstract level and to generate and coor- 
dinate required supporting system activities. The de- 
gree of coupling between reasoning at different levels 
depends in large part on the accuracy of the abstrac- 
tion. In the case of HST, decision-making at abstract 
levels is tightly coupled; each time a new observation is 
inserted into the sequence at the abstract level, control 
passes to the detailed level and supporting detailed sys- 
tem behavior segments necessary to achieve this new 
goal are developed. Given the imprecision in the ab- 
stract model, goals posted for detailed planning cannot 
be rigidly constrained; instead preferences are specified 
(e.g., “execute as soon as possible after obsl”). The re- 
sults of detailed planning at each step are propagated 
upward to provide more precise constraints for subse- 
quent abstract level decision-making. 

Model Decomposability and Incremental 
Scaling 

Large problems are naturally approached by decom- 
posing them into smaller sub-problems, solving the 
sub-problems separately and then assemble the sub- 
solutions. We can judge how the problem solving 
framework supports modularity and scalability by two 
criteria: 

# the degree by which heuristics dealing with each 
sub-problem need to be modified when adding sub- 
problem assembly heuristics to the problem solver; 

• the degree of increase of the computational effort 
needed to solve the problem versus the one needed 
to solve the component sub-problems 

To test the scalability of the HSTS framework, we 
conducted experiments with three models of the HST 
operating environment of increasing complexity and 
realism, respectively denoted as small, MEDIUM and 
LARGE model. All models share a representation of the 
telescope at the abstract level as a single state variable; 
they differ with respect to the number of components 
modeled at the detailed level. The small model con- 
tains a state variable for the visibility of each of the 
celestial objects of interest with respect to the orbit- 
ing telescope, a state variable for the pointing state of 
the telescope, and three state variables for the state 
of an instrument, the Wide Field Planetary Camera 
(WFPC). The MEDIUM model adds two state variables 
for an additional instrument, the Faint Object Spec- 
trograph (FOS), while the LARGE model includes eight 
additional state variables accounting for data commu- 
nication. The LARGE model is representative of the 
major operating constraints of the domain. Figure 1 
shows the relations among the various models. 

The problem solver for the small domain contains 
heuristics to deal with the interactions among the dif- 
ferent components of the WFPC (e.g., when a WFPC 
detector is being turned on, make sure that the other 
WFPC detector is kept off), with the pointing of the 
HST (e.g., select a target visibility window to point 
the telescope), and with the interaction among WFPC 
state and target pointing (e.g., observe while the tele- 
scope is pointing at the proper target). The heuristics 



Figure 1: The SMALL, MEDIUM and LARGE HST mod- 
els. 


added for the MEDIUM domain deal with the interac- 
tions within the FOS, between FOS and HST pointing 
state, and between FOS and WFPC. Since the nature 
of the new interactions is very similar to those of the 
SMALL model, the additional heuristics are obtained 
by simply extending the domain of applicability of the 
SMALL's heuristics. Finally, for the LARGE model we 
have the heuristics used in the MEDIUM domain, with 
no change, plus heuristics that address data commu- 
nication and interaction among instrument states and 
data communication (e.g., do not schedule an obser- 
vation on an instrument if data from the previous ob- 
servation has not yet been read out of its data buffer). 
The previous discussion supports the scalability with 
regard to the structure of the problem solvers. 

To verify scalability with respect to the degree of 
computational effort, we run a test problem in the 
small, MEDIUM and LARGE domain; the test consists 
of a set of 50 observation programs, each containing 
a single observation with no user-imposed time con- 
straints. The experiments were run on a TI Explorer 
II-h with 16 Mbytes of RAM memory. 

Table 1 supports the claim of scalability with re- 
spect to the required computational effort. The mea- 
sure of the size of the model (number of state variables) 
excludes target and communication satellite visibili- 
ties since these can be considered as given data. The 
number of tokens indicates the total number of dis- 
tinct state variable values that constitute the sched- 
ule. The temporal separation constraints are distance 
constraints that relate two time points on different 
state variables; their number gives an indication of the 
amount of synchronization needed to coordinate the 
evolution of the state variables in the schedule. 

Notice that since the heuristics that guide the plan- 
ning search exploit the modularity of the model and 
the locality of interactions, the average CPU time (ex- 
cluding garbage collection) spent implementing each 
required compatibility constraint (corresponding to an 
atomic temporal relation among tokens) remains rela- 
tively stable. In particular, given the high similarity of 
the nature of the constraints between the SMALL and 
the MEDIUM models, this time is identical in the two 
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Model 

SMALL 

MEDIUM 

LARGE 

State Variable# 

4 

6 

13 

Tokens 

5*7 

604 

843 

Time Paints 

588 

605 

716 

Temporal Constraints 

1296 

1328 

1474 

CTUTime/ Observation 

11.62 

12.25 

21.74 

CPU Time / Compatibility 

0.29 

0.29 

0.33 

Total CPU time 

9:41.00 

10:1130 

18:07.00 

Total Elapsed Tune 

1:08:36.00 

1:13:16.00 

254:07.00 

Schedule Horizon 

41:37:20.00 

54:25:46.00 

52:44:41.00 


Table 1: Performance results. The times are reported 
in hours, minutes, seconds and fraction of seconds 

cases. The total elapsed time spent generating an ex- 
ecutable schedule for the 50 observations is an accept- 
able fraction of the real time horizon covered by the 
schedules; this indicates the practicality of the frame- 
work in the actual HST operating environment. 

Exploiting Opportunism to Generate 
Good Solutions 

In the experiment just described, a simple dispatch- 
based strategy was used as a basis for overall sequence 
development: simulating forward in time at the ab- 
stract level, the candidate observation estimated to in- 
cur the minimum amount of wait time (due to HST 
reconfiguration and target visibility constraints) was 
repeatedly selected and added to the current sequence. 
This heuristic strategy, termed “nearest neighbor with 
look-ahead” (NNLA), attends directly to the global ob- 
jective of maximizing the time spent collecting science 
data. However, maximization of science viewing time 
is not the only global allocation objective. 

One critical tradeoff that must be made in space- 
based observatory scheduling is between maximizing 
the time spent collecting science data and satisfying 
absolute temporal constraints associated with specific 
user requests. The scheduling problem is typically 
over-subscribed; i.e., it will generally not be possible 
to accommodate all user requests in the current short 
term horizon and some must necessarily be rejected. 
Those requests whose user-imposed time windows fall 
inside the current scheduling horizon become lost op- 
portunities if rejected. Those without such execution 
constraints may be reattempted in subsequent schedul- 
ing episodes. 

As indicated above, the first objective (minimizing 
telescope dead time) is amenable to treatment within a 
forward simulation search framework. However, a for- 
ward simulation provides a fairly awkward framework 
for treating the second objective (minimizing rejection 
of absolutely const rained goals). A goal’s execution 
window may be gone by the time it is judged to be 
the minimum dead time choice. Look-ahead search 
(i.e. evaluation of possible “next sequences” and po- 
tential rejections) can provide some protection against 
unnecessary goal rejection but the general effectiveness 
of this approach is limited by combinatorics. A sec- 
ond sequencing strategy of comparable computational 
complexity that directly attends to the objective of 
minimizing rejection of absolutely constrained goals 


Sequencing 

Pctg. Constrained 

Pctg. Telescope 

Strategy 

Goals Scheduled 

Utilization 

NNLA 

72 

21.59 

MCF 

93 

17.20 

MCF/NNLA 

93 

20.54 


Table 2: Comparative Performance of NNLA, MCF 
and MCF/NNLA 


is “most temporally constrained first” (MCF). Under 
this scheme, the sequence is built by repeatedly select- 
ing and inserting the candidate goal that currently has 
the tightest execution bounds. This strategy requires 
movement away from simulation-based sequence build- 
ing, since the temporal constraints associated with se- 
lected goals will lead to the creation of availability 
“holes” over the scheduling horizon. Adopting a se- 
quence insertion heuristic that seeks to minimize dead 
time can provide some secondary attention to this ob- 
jective, but effectiveness here depends coincidently on 
the specific characteristics and distribution over the 
horizon of the initially placed goals. As is the case 
with the simulation-based NNLA strategy, one objec- 
tive is emphasized at the expense of the other. This 
second MCF sequencing strategy, incidentally, is quite 
close to the algorithm currently employed in the oper- 
ational system at STScI. 

Both NNLA and MCF manage combinatorics by 
making specific problem decomposition assumptions 
and localizing search according to these decomposition 
perspectives. NNLA assumes an event based decom- 
position (considering only the immediate future) while 
MCF assumes that the problem is decomposable by 
degree of temporal constrainedness. Previous research 
in constraint-based scheduling[SOM + 90] has indicated 
the leverage of dynamic problem decomposition selec- 
tive use of local scheduling perspectives. In the case of 
NNLA and MCF, one aspect of current problem struc- 
ture that provides a basis for selection at any point 
during sequence development is the current variance 
in the number of feasible start times remaining for in- 
dividual unscheduled goals. If the variance is high, 
indicating that some remaining goals are much more 
constrained than others, then MCF can be used to em- 
phasize placement of tightly constrained goals. If the 
variance is low, indicating similar temporal flexibility 
for all remaining unscheduled goals, then emphasis can 
switch to minimizing dead time within current avail- 
ability “holes” using NNLA. 

To test this multi-perspective approach, a set of 
short-term (i.e. daily) scheduling problems where 
solved with each base sequencing strategy and the 
composite strategy just described (referred to as 
MCF/NNLA). The results are given in Table 2 and 
confirm our expectations as to the limitations of both 
NNLA and MCF. We can also see that use of the op- 
portunistic MCF/NNLA strategy produces schedules 
that more effectively balance the two competing objec- 
tives. Further details of the experimental design and 
the strategies tested may be found in [SP92]. 
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These results should be viewed as demonstrative and 
we are not advocating MCF/NNLA as a final solu- 
tion. We can profitably exploit other aspects of the 
current problem structure and employ other decom- 
position perspectives. For example, the distribution 
of goals over the horizon implied by imposed temporal 
constraints has proved to be a crucial guideline in other 
scheduling contexts [SOM+90, Sad91j, and we are cur- 
rently investigating the use of previously developed 
techniques for estimating resource contention [MS87, 
Mus92J. There are also additional scheduling criteria 
and preferences (e.g., priorities) in space-based obser- 
vatory domains that are currently not accounted for. 

Conclusions 

In this paper, we have considered the solution of a 
specific class of complex scheduling problems that re- 
quire a synthesis of resource allocation and goal ex- 
pansion processes. These problem characteristics mo- 
tivated the design of the HSTS framework, which we 
briefly outlined and contrasted with other scheduling 
and AI planning approaches. To illustrate the ade- 
quacy of the framework, we then examined its use in 
solving the HST short-term scheduling problem. We 
identified three key ingredients to the development 
of an effective, practical solution: flexible integration 
of decision-making at different levels of abstraction, 
use of domain structure to decompose the planning 
problem and facilitate incremental solution develop- 
ment/scaling, and opportunistic use of emergent prob- 
lem structure to effectively balance conflicting schedul- 
ing objectives. The HSTS representation, temporal 
data base, and constraint-posting framework provide 
direct support for these mechanisms. 
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Abstract 

One of the problems that must be dealt with in ei- 
ther a formal or implemented temporal reasoning 
system is the ambiguity arising from uncertain 
information. Lack of precise information about 
when events happen leads to uncertainty regard- 
ing the effects of those events. Incomplete infor- 
mation and nonmonotonic inference lead to situa- 
tions where there is more than one set of possible 
inferences, even when there is no temporal un- 
certainty at all. In an implemented system, this 
ambiguity is a computational problem as well as 
a semantic one. 

In this paper, we discuss some of the sources of 
this ambiguity, which we will treat as explicit dis- 
junction, in the sense that ambiguous information 
can be interpreted as defining a set of possible 
inferences. We describe the application of three 
techniques for managing disjunction in an imple- 
mentation of Dean’s Time Map Manager. Briefly, 
the disjunction is either: removed by limiting the 
expressive power of the system, explicitly repre- 
sented, one disjunct at a time, or approximated 
by a weaker form of representation that subsumes 
the disjunction. We use a combination of these 
methods to implement an expressive and efficient 
temporal reasoning engine that performs sound 
inference in accordance with a well-defined for- 
mal semantics. 

1 Introduction 

One of the problems that must be dealt with in either a 
formal or implemented temporal reasoning system is the 
disjunction arising from uncertain information. Lack of 
precise information about when events happen leads to 
uncertainty regarding the effects of those events, and thus 
to uncertainty in what propositions are true at some point 
in time. Incomplete information regarding what proposi- 
tions are true when, and nonmonotonic inference (e.g., the 
persistence assumption or qualified causal projection) lead 
to situations where there is more than one set of possible 
inferences, even when there is no temporal uncertainty at 
all [6]. In a formal system, this ambiguity is noted and in 

^This work is supported by DARPA and the Air Force 
Rome Laboratory under Rome Laboratory contract F30602- 
90-C-0102. 


some way dealt with, either by changing the semantics to 

exclude it (e.g. by assigning a preference relation to the 

possible models of a given theory), or simply by acknowl- j 
edging it (i.e. couching conclusions in terms of the set of * 
possible models). 


In an implemented system, this ambiguity is a computa- 
tional problem as well as a semantic one. In this paper, 5 
we discuss some of the sources of this ambiguity, which 
we will treat as explicit disjunction, in the sense that am- 
biguous information can be interpreted as defining a set = 
of possible inferences. We describe how these sources of * 
disjunction are dealt with in our current implementation 
of Dean’s Time Map Manager [5; 2]. Briefly, we take one := 
of three approaches: B 


1. The disjunction is removed by limiting the expressive 
power of the system. 

2. The disjunction is explicitly treated, but the system 
considers only a single disjunct at a time. 

3. The disjunction is approximated by a weaker form of 
representation that subsumes the disjunction. 

The semantics that we are attempting to capture in our 
implementation are defined in [1], which provides a precise 
formal semantics for the current version of the TMM. 


I 


In the rest of this paper, we briefly discuss the ontology 
and semantics of the TMM, provide some specific examples 
of the kinds of disjunction that arise, and discuss the costs 
and benefits of various ways of handling these types of 
disjunction. 


2 The TMM 


Dean’s Time Map Manager [5; 2] is an implemented tem- 
poral reasoning system, intended as a foundation for build- 
ing planning and scheduling systems. The TMMincludes ca- 
pabilities for reasoning about partially-ordered events, per- 
sistence and clipping, and two simple forms of causal rea- 
soning: projection and temporal implication (sometimes 
called “overlap chaining” in previous work). The version 
of the system described in [5; 2] that was distributed from 
Brown (hereinafter referred to as “a-TMM”) implements 
forward persistence only, and does not implement tempo- 
ral implication. 


i 

i 


Besides these limitations, the inference performed by a- 
TMM is not sound for partially-ordered time points [3], and . 
bo has no well-defined semantics. For partial orders, the in- ^ 
ference done by the system is interpreted as quantification 
over total orders consistent with a given partial order: a _ 
formula of the form hoIds(t, P) is interpreted to mean that 
the proposition P holds at the time point t in all possible • 
total orders. The sense in which the original system is un- 
sound is that it will sometimes infer holds(t, P) when there . 
were total orders in which P does not hold at t. As Dean 
and Boddy show in the same paper, reasoning about what 
is true in the total orders consistent with a given partial 
order is an NP-complete problem. 

We have addressed these difficulties by implementing a ® 
sound but incomplete decision procedure that approxi- 
mates quantification over time points (t.e. # if the system 
infers holds(t, P), the proposition P does in fact hold at the S 
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time point t in every total order, but sometimes this prop- 
erty will be true and the system will not infer holds(t, P) 
[4]. We have made other extensions, including generalizing 
persistence to run backward as well as forward (in order to 
handle cases like Kautz's “parking lot problem.” [7]), and 
implementing temporal implication: reasoning in which the 
truth of some Bet of facts at a point can be used to conclude 
that some other fact is true at the same point. We have 
retained from the old system the concepts of persistence 
clipping and causal projection (referred to hereinafter as 
simply “projection”). 1 The new TMM implementation we 
will refer to as “/3 -tmm.” 

As far as we know, /3-TMM is the first implementation of 
sound-and-incomplete temporal reasoning as described in 
[4]. The process of implementing this decision procedure 
has made clear precisely how the resulting system is in- 
complete; this point will be addressed in Section ??. 

2.1 Ontology and Inference 

In this section we present a simplified version of the TMM 
representations that is sufficient for this discussion. A do- 
main theory in the language includes a time map and a 
causal theory . The time map consists of a set of time points 
T and a Bet of formulas. Time map formulas include the 
following: 

• Temporal relations between time points, denoted by 
the binary infix predicates <, <, =, >, and >, and 
the predicate distance(tl, t2, bounds ), where tl, t2 € 
T and bounds = [rl r2] where rl, r2 € !R are the 

, bounds of a closed interval. We represent temporal 
relations in the time map as constraints . 

• Temporal formulas, holds(ti, t2, P), where tl, t2 € 
T and P € V, the set of propositions . The period 
between tl and t2 is called the “observation interval” 
(throughout which the proposition must necessarily 
hold.) We use the abbreviation holds(t, P) when this 
interval iB a point. We represent temporal formulas 
on the time map using time tokens . 

• Persistence assumptions, persistsf(tl, P) 

and persists^ (t2, P), where tl, t2, and P appear in 
some temporal formula as above. We associate persis- 
tence assumptions with time tokens on the time map. 

The causal theory for a TMM theory includes causal rules, 
intended to encode the physics of a domain in a simple 
way, of the following kinds. 

• Projection rules, project((and (Pi, . . ., P*)), E, R). 
The propositions Pi,...,?* are antecedent^ E is a 
“trigger” proposition; R a forward-persistent “result” 
proposition. When the antecedent propositions are 
believed to hold throughout the trigger, the result is 
believed starting at a specified time after the trigger. 

• Temporal implication rules, (and (Pi,...,P*)) =>t 
At any point for which the propositions of the an- 
tecedent conjunction are all believed to hold, the re- 
sult proposition R is believed to hold. 


1 Details of extensions planned and accomplished can be ob- 
tained by request from Bob Schrag, at the address at the be- 
ginning of this paper. 


The TMM implements an epistemic semantics, in the sense 
that a proposition may be known (or believed) to hold at 
a point, or known not to hold at that point, or we may not 
know either way. This semantics is described more care- 
fully in [1]. The failure of the excluded middle in this se- 
mantics is useful for representing problems where we have 
only partial information. All of the propositions in the 
domain theory are believed necessarily. Temporal proposi- 
tions are believed necessarily at all points throughout their 
observation intervals. Inference from projection and tem- 
poral implication result in the addition of new tokens to 
the time map, representing belief in propostions holding 
for new intervals of time. Persistence iB captured in a pref- 
erence over models: those in which the appropriate facts 
persist are preferred over those in which they don’t. Con- 
flicts in these preferences result in ambiguous situations, 
where no single set of inferences can be preferred to all 
others. 

The theory including the time map and causal rules is in- 
tended to support the following kinds of inference. 

• holds(tl, t2, P): P is true in all possible worlds. 

• holds m (tl, t2, P): P is true in some possible world. 

• Inferences about necessary and possible temporal re- 
lations. 

• Boolean combinations of these. 

The first two kinds of inference concern belief in quantifica- 
tions of temporal formulas over possible worlds consistent 
with the user-supplied domain theory. The simplest form 
of ambiguity in the domain theory that can lead to multi- 
ple possible worlds results from a set of temporal relations 
that defines only a partial order on the set of time points. 

2,2 Sources of Disjunction 

There are several sources of disjunction in the TMM. There 
is one source of disjunction we have explicitly removed: 
there is no way to assert an explicit disjunction in the 
domain theory. You can say that proposition P is true 
at time t, and that point tl is ordered before point t2. 
You cannot, for example, say that tl and t2 cannot occur 
simultaneously (i.e., they are definitely ordered one way 
or the other). 

This leaves us with two main classes of disjunction to deal 
with. The first is the temporal uncertainty resulting from 
the fact that we do not require time points to be totally 
ordered. Actually, there is additional metric uncertainty: 
we can specify the distance between two time points only 
as a range without that meaning that there is any uncer- 
tainty in ordering anywhere in the time map. Metric tem- 
poral uncertainty is straightforward to deal with. It affects 
no inference more complicated than directly determining 
whether a proposition holds at a point. Partially ordered 
points are a more complex problem because ordering af- 
fects which inference rules fire. For either projection or 
temporal implication, whether the rules fire is based solely 
on ordering relationships: all the possible assignments to 
temporal relations consistent with a given toted order are 
equivalent, as far as which causal rules will “fire.” For this 
source of disjunction, the “possible worlds” are the total 
orders consistent with the given partial order. Deciding 
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whether a proposition holds at a point necessarily, possi- 
bly, or not at all becomes a question of quantifying over 
the set of total orders. In Section 3, we discuss how this is 
accomplished (approximated, actually) in the TMM. 

The other source of disjunction we must consider is a di- 
rect result of the semantics we impose on the system: the 
persistence assumption. Nonmonotonic reasoning has been 
recognized by many people at many times as a source of 
ambiguity and unintended conclusions (most relevant to 
our work is Hanks and McDermott’s paper on applying 
nonmonotonic logic to temporal reasoning [6]). Unfortu- 
nately, it appears to be too useful to dispense with. Simply 
stated, the persistence assumption says that things tend 
not to change unless something changes them. If I walk 
into a room, see that the light is on, and walk out again, 
it seems both reasonable and useful to conclude that the 
light was on before I got there, and again after I left. 3 
Contradictory information (e.g., walking into the room at 
a later point and noticing that the light is off) will cause 
the system to draw different conclusions. The persistence 
assumption can lead to ambiguous conclusions in a wide 
variety of situations, a representative sampling of which 
are discussed in Section 4. 

In the examples in the following sections, we represent 
time maps as follows: A time point is represented by a 
dot: •. An observation interval is represented by two 
time points connected by a line: a #. Temporal or- 
dering is from left to right, and all points are drawn 
with respect to a given frame of reference. When a time 
point is connected to a solid line, we know its relation 
with respect to the reference exactly. A dashed line as 
in - • indicates uncertainty about the point’s loca- 
tion. Forward and backward persistence are represented 
by forward- and backward-pointing arrows: «♦— , — We 
label tokens with the corresponding propositions and we 
label time points when we need to refer to them: • . A lone 
timepoint with a proposition label is a sero-length 1 observa- 
tion interval*# P. A single time point with a persistence 
symbol is a persistent version of the same thing: •-»- P. 

To illustrate, here is a simple time map situation demon- 
strating the firing of a projection rule. Relevant textual 
information is displayed above the time map. 

project(P, E, R) 

§■ • P 

• • E 


3 Partial Orders 

The problem with partially-ordered time maps is that in- 
ference such as projection and temporal implication de- 
pend on what facts hold at a given point, Thisrelation 
is defined only for totally ordered points, and so we are 
reduced to determining what facts might possibly or nec- 
essarily hold at a point, in some or all of the total orders 


3 How “reasonable" persistence is, is context-dependent. 
Consider the same example where I see a cat sleeping on a 
chair, or a newspaper on a seat on a train. 
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consistent with the given partial order. With even a very 
simple causal model, this is an NP-complete problem [4]. 

The solution we have implemented (first presented in [3]) = 

is to approximate the necessary quantification. — 


/J-TMM includes two holds definitions which together pro- 
vide a sound-and-incomplete temporal reasoning algorithm 
which executes in polynomial time. Each definition ap- 
proximates a quantification over the possible worlds con- 
sistent with the domain theory, holdss ( strong holds) is 
a sound-and-incomplete approximation to holds. We use 
holdss to identify a subset of all necessarily believed tem- 
poral propositions. holds w ( weak holds) iB a complete-and- 
unsound approximation to holds m . We use holds w to iden- 
tify a superset of all possibly believed temporal formulas. 
In the presence of inference such as projection, the strong 
version requires the weak version: a proposition necessarily 
holds over an interval unless there is a possibly-derived to- 
ken (the result of a projection rule, or added by the user), 
which possibly contradicts (clips) that proposition for some 
part of that interval. 

holdss is incomplete in two ways: 
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• It avoids combinatorics by looking for a single token 

to span the query interval for all possible worlds. It ^ 
will fail in a case where the interval is spanned by ^ 
different tokens in different total orders. ™ 

• It relies, ultimately, on the over-achieving holds w to 

defeat the strong tokens’ persistences. ^ 

holds w is unsound in two ways: B 


• It avoids combinatorics by checking for a conjunction 

of possibilities rather than a possible conjunction. It jg 
succeeds sometimes when the conjuncts are not mu- Jg 
tually sat isfi able. 

• It relies, ultimately, on the under-achieving holds$ to 

defeat the weak tokens’ persistences. ^ 

Some of these points are illustrated in the following exam- * 
pies. 


Example 1: Incompleteness in holdss can arise directly 
from opposing contradictory persistences. 

projectfP, E, R) 
project(-«P, E, R) 

P •-+ iP 

ti , « E 

t3 


Our semantics says that the persistences for P and -iP clip 
at some point between tl and t2l, but not where. One of 
P or -»P covers E in all total orders, so hold$(t3, R). We are 
limited to holds w (t3, R). 

Example 2t Unsoundness in holds w can arise directly 

from partially ordered timepoints. f 

distanceftl, t2, 3) 
distance(t3 f t4 f 5) 

• — — 4 P 

w m m t3 E 

t3 t4 


P 


does 
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not cover E in any possible world, bo -iholdsmfaS, t4, P)— 
but the conjunction of possible temporal relations in 
holds w (t3, t4, P) is satisfied, and it succeeds, unsoundly. 
Even though we do not have (tl < t3 Am t2 > t4), we do 
have (tl <m t3 A t2 >m t4). 

Example 3: Incompleteness in holds$ can arise indirectly, 
through weakly and unsoundly derived defeaters. 

distance(ti, t2 f 3) 
distance(t3, t4, 5) 
project(P ( E, R) 

— • P 

♦ ta E 
4 W R 

• -.R 

t5 

From Example 2 above, we know the token for R is weakly 
and unsoundly derived, and we should have holds(t7, -iR). 
But -»R is defeated weakly and unsoundly and we are lim- 
ited to hold5w(t7, -»R). 

While strong inference (holdss) is incomplete in a well- 
defined and limited sense (checking a single token), the 
approximate nature of weak inference (holds w ) is less pre- 
cise. There are tradeoffs that can be made. For example, 
it is possible to add or omit a check on the maximum pos- 
sible extent of a given token, rather than just the ordering 
of the endpoints. Adding such a check would result in a 
system that handled Example 2 correctly. At an additional 
computational expense, of course. 



4 Ambiguous Models Resulting 
From Persistence 


The persistence assumption combines with temporal impli- 
cation or projection to generate situations in which there 
are several possible models for a given domain theory. In 
other words, we can construct theories in which P is true at 
sorpe time T in some models (possible worlds) and false in 
others. These situations arise even if we limit ourselves to 
theories where all temporal relations are precisely specified 
for every point in the time map. In the following scenario, 
there are two temporal implication rules and four tokens 
specified in the domain theory (the dashed line on the right 
hand side separates a picture of the initial conditions from 
three different “possible worlds” corresponding to different 
models that can be constructed). 

Example 4: Temporal implication with persistence can 
be ambiguous. 

Rl: (and P Q) =>t 
R2: (and M I) =>t 


P 


I 


p 





M 


__ V 

n 

^wona - 



P 

(world 2) — 1 

q 

I 

M 


P 


(world 3) 



V 


M 


In the first possible world (below the first dashed line) we 
maximise the extent of P’s persistence. The result of the 
temporal implication rule Rl, forces us to clip the persis- 
tence of M just after the end of Q. This world will be pre- 
ferred to any world that is the same as this world except 
that P stops being true at some point after the end Q due 
to the persistence assumption: we prefer for P to persist 
as long as possible. Multiple models, and thus ambiguity 
or disjunction, result when there are several models none 
of which is preferred over any of the others. 3 There is a 
symmetric case, in which M’s persistence is maximized. In 
the second model, the persistence assumptions for P and 
M are maximized with respect to each other. Neither of 
the rules come into play in this interpretation. They arc 
maximal with respect to each other in the sense that if 
you extended either, the others’ extent would be reduced. 
Finally, consider a case where P (or symmetricaly M) is al- 
lowed to persist to some point within the extent of Q (l). 
The third picture shows one of an infinite number of pos- 
sible worlds that can be obtained in this way. In each of 
these worlds, the persistence of P and Q are maximized 
with respect to each other in the same sence as described 
above. 

It is not difficult to come up with similar scenarios in- 
volving projection and backward persistence; or temporal 
implication and forward persistence. In fact fairly complex 
scenarios can be created using chains of projection rules, 
temporal implication rules, and persistence. There is an 
easily-identifiable condition of the causal theory that is 
necessary but not sufficient condition for theories to entail 
these kinds of ambiguities. Basically, we look for certain 
kinds of cycles using static analysis of the rules. Consider 
a DAG created from the rules as follows: 

• Create a node in the DAG for each unique antecedent 
and consequent proposition 

• For each rule create an arc from each antecedent node 


s For a more careful discussion of the use of model preference 
to model persistence see e.g., [8; 1] 
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to the consequent node 

• For each consequent node create an arc to each con- 
tradictory antecedent 

If any cycles exist in this DAG then our theory may entail 
the kind of non-monotonic disjunction describe above. 

We have identified two approaches to implementing a prac- 
tical system that deals with this kind of disjunction: 

• Don’t deal with it at all. Use the static rule analysis 
technique described above to reject rule sets that may 
entail this kind of disjunction. 

• Use an approximation that is sound and incomplete. 
The idea is to be extremely conservative when looking 
for possible ambiguities. Any time there is a rule that 
may participate in a cycle of the sort described above, 
prohibit any backward persistence from being used as 

ii an antecedent. 

Both approaches are rather heavy-handed: the analyze- 
and-complain approach leaves the user either without func- 
tionality or without predictability; both approaches over- 
react to prevent situations that may not occur, on the 
grounds that specific situation detection is too expensive. 
This will be a further source of incompleteness in the infer- 
ence the system does. The complaining approach can be 
turned into a warning approach that goes on to do weak 
clipping. 
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5 Summary 


In this paper, we have identified the sources of disjunction 
that must be considered in a temporal reasoning system 
that handles partially-ordered time points, forward and 
backward persistence, and two simple forms of causal rea- 
soning. These sources can be grouped roughly into two 
classes, one corresponding to problems arising from tem- 
poral uncertainty (partial orders), the other the result of 
the nonmonotonic persistence assumption. There is actu- 
ally a third source of disjunction that we have finessed by 
restricting the expressive power of the system: we do not 
permit the expression of explicit disjunctive propositions. 

We have demonstrated three general classes of methods 
for dealing with disjunction, and proposed specific fixes for 
specific problems. Where possible, we have described im- 
plemented solutions from our work on the TMM. This pa- 
per presents the first clear characterization of the sources of 
incompleteness in the sound-and-incomplete decision pro- 
cedure described in [4]. 

The techniques we have developed for managing disjunc- 
tion are crucial to our implementation of an efficient tem- 
poral reasoning system. In particular, the representation 
of a set of disjunctions by some simpler description of a 
larger set including those disjunctions is a powerful tech- 
nique that has found repeated use for handling disjunctions 
with a wide variety of sources and characteristics. With 
a little care, the resulting system retains the property of 
soundness, which we regard as crucial to the implementar 
tion of a useful system for temporal reasoning. 
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Abstract 


Scheduling if the task of assigning resources to operations. When the resources are mobile vehicles, they 
describe routes through the served stations. To emphasize such aspect, this problem is usually referred to as 
the routing problem. In particular, if vehicles are aircraft and stations are airports, the problem is known as 
aircraft routing. This paper describes the solution to such a problem developed in OMAR (Operative 
Management of Aircraft Routing), a system implemented by Bull HN for Alitalia. In our approach, aircraft 
routing is viewed as a Constraint Satisfaction Problem, ifhe solving strategy combines network 
consistency and tree search techniques. 


1. Introduction 

Two of the main concerns for a major airline are 
flight planning and aircraft routing. 

Flight planning involves both technical and 
market issues, such as the choice of the cities to 
be served and the weekly frequency of flights. It 
produces an aircraft rotation, valid for a whole 
season, which we shall refer to as the virtual plan 
(see fig. 1); it consists of a periodical time table 
where flights are organized in lines, one for each 
virtual aircraft, an hypothetical resource that 
could perform them in absence of technical and 
maintenance constraints. 

Aircraft routing assignes tail numbers - the 
identifiers of the aircraft - to flights, usually for a 
time window of 24 hours. This process, called 
predictive routing, is trial and error: routes are 
drawn on the virtual plan, performing switches, 
i.e. connections between flights on different lines 
of the plan, to satisfy the constraints that prevent 
an aircraft to cover the next flight on the same 
line. When there are no more tasks available for 
the given aircraft, an assignment to an already 
scheduled task is possibly invalidated. If the 
scheduler is not able to cover all the activities 
with the available resources, maintenance are 


delayed or, in some extreme cases, flights are 
dalayed or even cancelled. The schedule 
produced by predictive routing is coded in the 
routing plan, which differs from the virtual plan 
in replacing virtual with actual aircraft and 
arranging programmed maintenance. The routing 
plan is often modified in real time to avoid or 
contain, propagation of delays. Such an activity 
is said reactive routing. 

This paper describes the Prolog kernel of OMAR 
(Operative Management of Aircraft Routing), an 
interactive system designed to provide predictive 
and reactive routing of the Alitalia fleet. Routing 
is formulated as a Constraint Satisfaction 
Problem (CSP): each variable (task) has a 
domain of possible values (aircraft) while 
constraints (relations between variables) are used 
to restrict such domains. Since the refined 
domains are not in general single-valued, 
solutions must be found by search, iteratively 
selecting an aircraft and assigning it to a set of 
consecutive flights. Aircraft selection is driven by 
the first fail principle: the most constrained 
aircraft is scheduled first. A controlled form of 
backtracking is implemented to partially recover 
from heuristics flaws while maintaining 
predictable response time. 
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2. Problem Definition 

In this section we give a formal definition of both 
predictive and reactive aircraft routing. 

The constraints of the problem are captured by 
the function label, that associates to each task the 
set of aircraft that can perform it. The function 
startq S returns the airport from which an aircraft 
has to depart after time the start time of the 
scheduling window. 

Predictive Routing 

Input 

set T of tasks 
set AP of airports 
set AC of aircraft 
set Q of times 

schedule start time % and schedule end time qe 
total order Son Q u (qs) u (q e ) s.t. Vq€ Q, qj S q S q e 
total function departing time, dt: T -> Q 

total function arrival time, at T -> Q 

total function departing airport, da: T -> AP 

total function arrival airport, aa: T -> AP 

total function label, label: T -> 2 ^C 

total function start,,, start,,: AC -> AP 

Output 

an aircraft routing, i.e a total function s: T -> AC, s.t. 

0) V te T, s(t)e label(t) 

(ii) if s'l(ac) is not empty, then its elements can be 
ordered in a sequence (the routing path of ac) 

r ac =<t *c,o»t*c,i tac.ii> such that 

da(t^.o) = start,, (ac) 

aa(t»c.i-l) = i= 1 ... ,n 

a l(t»c,i-l) < dt(t lc> i) i=l,..,n 


Reactive Routing 
Input 

aircraft routing as defined above 
an unexpected event 

Output 

an aircraft routing that copes with the unexpected event 
and most closely conforms to the given routing. 


3. Aircraft Routing as a 

Constraint Satisfaction Problem 

A task is said programmed if its departure and 
arrival airports and times are fixed. Flights, as 
well as main maintenance, are programmed, 
whereas secondary maintenance not necessary. 
The duration of each task is a given constant. Let 
us assume that we have a set T = [T^, 

h=l,...,m} of programmed tasks to be scheduled 
in a time window of 24 hours. 

Two tasks Tjj and T^ are said to be connectible 
(denoted Tjj -> T^), if the following Prolog 
clause holds: 

connectiblefTh.Tk):- 

task_arrival_airport(ThAirp), 

task_departure~jjurpdrt(Tk\Mrp), 

task_arrivaljime(ThMinArrT), 

task_departurejime(TkMaxDepT ) . 
ground_time(Airp,GrT), 

ArrTO is MinArrT + GrT, 

ArrTO < MaxDepT. 

In other words, task T^ is connectible to task T^ 

iff the arrival airport of the former is equal to the 
departure airport of the latter and the arrival time 
of the former plus the ground time precedes the 
departure time of the latter. The graph of the 
connectibility relation is said the connection 
graph. It is directed and acyclic. Fig. 2 shows the 
connection graph for the portion of virtual plan in 
fig. 1. 

We say that T^ precedes T^ and write T^ < T^ iff 
(Th.Tfc) is in the transitive closure of ->. If 
neither Tjj < nor Tjj < T^, then Th and Tk are 
said incompatible, denoted T h >/< T k : 

incompatible tasks cannot be assigned to the 
same aircraft. A routing^ path P is a finite 
sequence of elements from T 

P = <Tl, T2 T n > 

such that Th -> Th+l for each h, 1 £ h < n. A 
path S is operable by aircraft Ac if each task in 
the path is operable by Ac, i.e. there are no 
technical reasons that forbid the assignment to 
Ac. 
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An initial state for the fleet is a one-to-one map 
from Acs, the set of aircraft in the fleet, to a 
subset of T, the set of programmed tasks. The 
image of Acs under such map is the set of initial 
tasks of T, which correspond to those nodes in 
the connection graph with no entering arcs. The 
set of final tasks is the set nodes in the 
connection graph with no exiting arcs. In the 
following, paths will have an initial task as first 
element of the sequence; the idea is that paths are 
the formalization of the routes that an individual 
aircraft may cover, starting from its initial state. 

We look at the elements of T as variables which 
take their values from the domain Acs. As 
already mentioned, a label of a task is the set of 
aircraft that can perform it. This concept can be 
extended to the set of all tasks: the labeling of the 
set T is a map 1 : T -> P(Acs), where P( Acs) is 
the powerset of Acs. 

Constraints are relations in Acs x P( T) that are 
used to refine the labels of tasks. They come in 
two types: a commitment constraint between 
aircraft Ac and tasks Ti,...,Tn requires that Ac 
executes at least one of those tasks; an exclusion 
constraint between an aircraft Ac and and tasks 

Ti T n requires for Ac to be excluded from 

those tasks. 



Fig. 1. A portion of about one-fourth of 
the virtual plan for the DC -9 fleet. 


Each singleton labeling that satisfies all the 
constraints is an aircraft routing, i.e. a solution to 
the routing problem formalized in sect. 2. Such a 
singleton labeling generates a partition of the set 
T of tasks such that each element of the partition 
is a routing path for a distinct aircraft 


4. Routing Process 

The routing process implemented in OMAR starts 
loading the state of the fleet and the relevant 
information on the tasks to be scheduled from the 
Alitalia database. A necessary, but not sufficient, 
condition for the existance of a fleet routing is 
checked, namely whether the number of 
resources available to be assigned to each task is 
always greater than or equal to zero. We briefly 
describe the algorithm, linear in the number of 
tasks, that tests such condition. 

Each airport airport served by the fleet identifies a 
sequence of chronologically ordered events 
belonging to one of two classes: departures or 
arrivals. Each task entails two events, its arrival 
and departure, unless it is initial, in which case 
we consider only the arrival. A resource counter 
representing, at each time, the balance between 
arrivals and departures, is associated at every 
airport. The resource counter is initially set to 0 
and is incremented or decremented, at each flight 
arrival or flight departure, respectively. If, 
scanning the whole plan, the counter of some 
airport becomes negative, the necessary condition 
is not satisfied and no routing exists. On the 
other hand, if the counters are always grater than 
or equal to zero, then the condition is satisfied 
and die system enters its next stage. 



Fig. 2. The connection graph for the 
virtual plan in fig. 1. 
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A sample list of events at Linate airport is shown 
below. 


Time 

Event 

Flight 

Resource Level 

17:50 + 0 

d 

448 

0 

1 7:25+35 

a 

267 

1 

1 7:45+35 

a 

074 

2 

18:30 + 0 

d 

31 6 

1 


Observe that the arrival of flight 267 at 17:25, 
given the ground time of 35 minutes, follows the 
departure of the flight 448 at 17:50. 


The constraint satisfaction algorithm refines the 
labels so that most dead-ends are avoided and 
expiry maintenance requirements are implicitly 
satisfied: this means that aircraft planned for the 
latter tasks are excluded by those routes that do 
not lead to the set of airports where maintenance 
jobs are possible. 

If the network is not found consistent, no 
complete routing exists and the control goes to 
the human scheduler who relaxes the constraints. 
It is our opinion that this kind of expertise cannot 
be adequately simulated by a computer, since the 
knowledge required to recognize the causes of an 
inconsistent situation and suggest a solution is 
too extended and fuzzy. If, on the other hand, 
everything is succesfull, the system is ready to 
schedule. 

The aircraft are sorted in decreasing order 
according to the number of occurrences inside the 
labeling; the idea is that the aircraft coming first 
in this order are the most constrained ones, since 
they have a smaller number of tasks on which 
they can be enrouted. Routes are then created 
according to such an order by the Prolog 
procedures sketched below. 


route jgen([ Ac] Acs] LabfiewLab):- 
pathgen(AcLab,TmpLab), 

i 

■ I 

route jgen( Acs, TmpLabflewLab). 
route _gen([] JxtbJLab). _ 

path _gen(AcLabfJewLab):- 

last_started(Ac,Task), 

path jgen(Ac, Task JLabfJewLab). 

paih_gen(Ac,TaskLabMewLab):- 

select(Ac,TaskJLabfiexiTask,TmpLab), 

path_gen(AcflextTask,TmpLabf!ewLab). 

path_gen(_Ac,_TaskfabLab). 


The recursive procedure route jgen/3 terminates 
when the list of aircraft to be scheduled is empty. 
It searches for a solution in depth-first mode, 
generating a descendant of the most recently 
expanded node and backtracking if some dead 
end is reached. If we relied exclusively on 
backtracking, the process duration would be 
unpredictable. Fortunately, we have developed 
some criteria that help us to discard paths likely 
to fail. On each aircraft Ac, route_gen/3 calls 
pathgen/ 3, passing as parameters the aircraft Ac 
and the labeling Lab and returning a new labeling 
TmpLab in which the tasks assigned to Ac are 
the generated path. The procedure pathgen/4 
builds a path recursively, task after task, starting 
from the first one returned by last_started/2. 

A limited amount of backtracking is allowed: 
different choices are considered only during the 
coupling of a task with one of its direct 
offsprings. Yet paths cannot be invalidated after 
its completion (note the use of the cut sign '!' 
after pathgen! 3 ). In case of failure, the interaction 
with the user is more effective. In our 
experience, after the relevant modifications have 
been performed, another run of the scheduler is 
usually sufficient to achieve a complete solution. 

Let us analize the path generation process in more 
detail. The problem is not trivial, since there are 
both local and global optimizations which 
influence the choice at various extents, often in 
opposite directions. For instance, we could 
always choose the first task departing after the 
given one (local optimization), but this could 
generate a new line switch hard to manage in the 
overall routing (global optimization). 


seleci(Ac,TaskLabMexiTask JJewLab) 

propose(Ac Jask lMb^exiT ask), 
check j-c(TaskbJextTask), 
update _lab( Ac MextTaskLabflewLab). 

propose(Ac,TaskLabMextT ask) :• 

get_methods(Ac,TaskMethods), 

merhber(MethodMethods), 

offsprings(T ask, Offs), 
choose(Method Ac. Offs. Task flexiTask). 

get_method(Ac,TaskMethods):- 

rule( Condition Methods), 
apply(ConditionAc,Task). 

rule(open_switch, [ close_switchstraight, closest, stop]). 
rule( default, [straight, open_switch,closeststopJ). 




The basic step of the path generation process is 
performed by the Prolog procedure select/5 
shown above. Given an aircraft Ac, just assigned 
to a flight or maintenance (Task), select/5 extends 
the path of Ac to a new flight or maintenance 
(NextTask). The procedure propose/4 returns 
Nextask, then check jc/2 checks whether the 
resource counter becomes negative: in such a 
case it fails, otherwise it succeedes and the 
labeling is updated, aircraft Ac being assigned to 
NextTask. The path of Ac is extended with 
NexTask by propose/4 as follows: first, a list 
Methods of methods compatible with Ac and 
Task is selected by get_methods/3\ then, one 
Method is chosen nondeterministically from such 
a list; after, the offsprings of Task in the 
connection graph are returned by offsprings/2 
and finally, one of them, NextTask, is returned 
by choose/5 , which basically applies Method to 
the given Ac and Task. 

A method is a technique to choose the next task 
that extends a given path. Methods are gathered 
in lists and are associated to conditions. The 
relation between conditions and lists of methods 
is defined by rule/2. Two sample rules are shown 
above for the open_switch (remember that an 
aircraft opens a switch when its path is extended 
on a different row) and the default conditions. 
Given Ac and Task, if a condition is applicable to 
Ac and Task, which is checked by apply/3, a list 
of methods is returned by getjnethods/3. Such 
methods are tried in the same order as they 
appear in the Methods list, the first one being the 
most desirable. For any possible Ac and Task 
there is at least one rule whose condition is 
satisfied, thus a list of methods is always 
selected, eventually by the default rule. In such a 
case, the list of methods tries to extend the path 
on the same line of the virtual plan with the 
straight method, which is considered optimal, 
otherwise a switch is opened by open_switch\ if 
it is not possible to open a switch, the closest 
flight is selected by closest to minimize the 
consumption of the resources; if even this 
method is not applicable, the path is terminated 
by stop. 


5. Conclusions 

Aircraft routing is a problem for which no exact 
solution is known. Consequently, all models are 
heuristic and research is now concentrating on 
the systematic interaction between human and 
computer. 


OMAR is an interactive system for the routing of 
the Alitalia fleet. Its kernel is presently composed 
of 20,000 lines of Quintus Prolog source code, 
and the system's response time is satisfactory. 
Once the derived structures have been computed 
from the primary database, the fleet routing is 
returned nearly in constant time (approximatively 
30 seconds for a fleet of 26 aircraft with 170 
flights). 


Moreover, if the constraints are compatible with 
complete schedules, there is a very high 
probability that the system succeeds finding one 
of them. Of course, we cannot expect that the 
solution perfectly matches the user's 
expectations. According to our experience, 
however, an intervention by the user modifying, 
on average, five assignments, is suffucuent to 
reach such an accomplishment. 

In the tests supplied by Alitalia so far, OMAR's 
solutions can be compared with those of a senior 
scheduler. 
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Planning is commonly viewed as a task to devise a course of action or a plan that conforms as 
much as possible to a set of goals before acting. The plan will then be used to guide the activities. 
Most classic planning systems assume a static environment for the planning agents. In a static 
environment, states remain unchanged between actions, and the outcomes of actions are assumed 
to be deterministic. In reality, however, most applications are dynamic and stochastic in nature. 
External events, not caused by controlled actions, may occur; outcomes of actions may differ from 
expectations; new constraints may be introduced; and a new set of goals may evolve in response 
to the changes. Recently, we have proposed a multi-modal framework for adaptive planning in a 
dynamic environment with multiple objectives having the following characteristics: 



• some of the objectives of the planning process may be conflicting 

• some objectives may be ill- defined or difficult to measure quantitatively 

• the objectives may change over time 


The task domain of production planning and scheduling is a typical example of such an environ- 
ment. The scheduling objectives typically include the following: meeting flue dates; reducing lead 
times; reducing work-in-process and finished goods inventories; maximizing resource utilization and 
the throughput of the system; and minimizing the sensitivity of the schedule to random events. 
These objectives are sometimes in conflict with each other. In our previous work, we developed a 
real-time distributed scheduling system 1 that observes its environment from different perspectives. 
These perspectives stem from the different objectives, and the system can react to events as they 
occur while monitoring the various objectives. This multi-perspective monitoring helps our system 
achieve better control of the environment. During our study, we discovered that although these 
global objectives may not change over time, the relevance of each objective is actually a function 
of time and the state of the system. For example, given a set of N objectives 0%, 0 2 , ... 0 n , at 
time fi, objective 0 2 naay be significantly more important than Oi, whereas at another instance 

^or a detailed^ description of the system, please read the attached paper titled “An Architecture for Real Time 
Distributed Scheduling” to appear in “Applications of AI in Manufacturing,” published by AAAI Press, edited by 
Dana S. Nau. 
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of time > objective Oi may become most important. Furthermore, each heuristic implies a set of 
reactive strategies that move the system toward some objectives but away from other objectives 
(due to the conflicting nature of these objectives). 

^^In our current researchi ng d evise a qualitative control layer to be integrated into a real-time 
multi-agent reactive planner: The reactive planning system consists of distributed planning agents 
attending to various perspectives of the task environment. Each perspective corresponds to an 
objective. The set of objectives considered are sometimes in conflict with each other. Each agent 
receives information about events as they occur, and a set of actions based on heuristics can be 
taken by the agents. Within the qualitative control scheme, we use a set of qualitative feature 
vectors to describe the effects of applying actions. A qualitative transition vector is used to denote 
the qualitative distance between the current state and the target state. Given a target state and 
a set of heuristics, we have an algorithm to test the reachability of the target state. We will then 
apply on-line learning at the qualitative control level to achieve adaptive planning. Our goal is 
to design a mechanism to refine the heuristics used by the reactive planner every time an action 
is taken toward achieving the objectives, using feedback from the results of the actions. When 
the outcome is compared with expectations, our prior objectives may be modified and a new set 
of objectives (or a new assessment of the relative importance of the different objectives) can be 
introduced. Because we are able to obtain better estimates of the time-varying objectives, the 
reactive strategies can be improved and better prediction can be achieved. 
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Abstract 

This paper discusses an attempt to solve the 
problem of planning several pharmaceutical 
plants at a global level. The interest in 
planning at this level is to increase the 
global control over the production process, to 
improve its overall efficiency and to reduce 
the need for interaction between production 
plants. In order to reduce the complexity of 
this problem and to make it tractable, some 
abstractions have been made. Based on these 
abstractions, a prototype is being developed 
within the framework of the EUREKA 
project PROTOS, using Constraint Logic 
Programming techniques. 

Introduction 

This paper describes the development of a proto- 
type “global planning toor within the framework 
of the EUREKA project PROTOS [PROTOS90]. 
PROTOS aims at the application of Prolog-based 
techniques to real-life planning and scheduling 
problems. The problem addressed by this proto- 
type was proposed by one of the PROTOS part- 
ners, which is a large swiss pharmaceutical 
company. 

The whole production of this company is split 
over several plants. The aim is to compute a global 
production plan for all these plants. Up to now, 
there is no such global plan, and all the coordination 
and adjustments of the production process between 
the different plants is achieved through phone calls 
between plant managers; there is no global control. 
This scheme works because of the experience and 
know-how of the plant managers, but the result is 
far from optimal. 

If a good global plan could be provided, ensur- 
ing that no major coordination problem should 
occur, then each plant could make local optimisa- 
tions as long as the constraints imposed by the glo- 
bal plan are respected; also the resulting production 
process would become much closer to optimality. As 
a side effect, this global plan would also reduce the 


need for the phone call based coordination, although 
it is not expected to suppress it totally. 

As it is far too complex to take into account all 
details of the local data of each individual plant, the 
considered global planning tool is based on an 
approximation of the local reality. Thus, the output 
of this tool is only a "rough” global plan, that will 
then be further refined at each plant, by the local 
scheduling tool (in this case a job-shop scheduling 
tool). 

The implementation tool chosen was the 
Prolog III system [CoI90], in order to take advan- 
tage of the recent advances in the Constraint Logic 
Programming field [Coh90, VH89]. 

1 Problem description 

Scheduling problems are known to become quickly 
intractable, because of combinatorial explosion. 
This gets even worse when trying to compute a 
global plan for several plants, as it is practically 
impossible to consider all details of each plant. 
This problem has to be simplifiedsomehow. 

The work described here is based on one approxi- 
mation of the local reality, which is the abstrac- 
tion of individual machines in machine groups. 

In order to define a machine group, some terms 
have to be introduced: 

• the word "product” designates both intermedi- 
ate and finished products. 

♦ several production steps are needed to go 
from one or several intermediates to the prod- 
uct of the next upper level; all these steps are 
grouped in a single "production order”. 

A machine group is a set of machines located 
physically close to each other, and each order can be 
completely executed using only machines within one 
machine group. 

Also, at the global planning level, the different 
production steps of one order are abstracted in only 
one production task. Thus, one order is considered 
as being one task using one resource. 
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The global planning tool takes as input: 

1. demands for finished products, a demand 1 be- 
ing a pair (amount, due date), 

2. the allocation of machine groups to products 
(each product is considered as being always 
produced on the same machine group), 

3. the dispositive bill of materials : 

E.g. dispositive bill of materials with machine 
group allocation to products: 


disposition 
level 0 


disp. 
level 1 


disp. 
level 2 


mg2 



mg 


Legend: 

* circles are products, 

* an arrow from A to B means that product 
A is an input to the production of B, 

* a number n near an arrow between A and 
B means that n units of product A are 
needed to produce 1 unit of product B, 

; * shapes round products represent machine 

group allocation: e.g., products P1,P2 and 
P3 will be produced on machine group 
mgl. 

4. stock data, 

5. eventually, existing machine group alloca- 
,;i tions to some orders. 


to minimize stocks. 

While it is hoped that a conflict-free solution can 
be found in most cases, this might not always be 
the case because of the abstractions/approxima- 
tions made. When no conflict-free solution exists, 
the global planning tool has to generate the best 
imperfect solution (i.e. featuring some conflicts on 
resource allocations). This best imperfect solution 
can then be used at the local scheduling level, 
which still has some flexibility that does not ap- 
pear at the global planning level, and which could 
possibly solve conflicts. 

The complexity of the problem not only comes 
from the number of demands to plan, but also 
from the handling of stocks and residuals: 

• stocks may be available at the beginning of 
the planning period; 

• additional stocks are likely to be generated 
during the production process because of 
some production constraints: it is not possible 
to produce less than a minimum quantity of a 
product at once (minimal lot size); 

• residuals can be regenerated during the pro- 
duction process: e.g. the production of Z3 re- 
generates a certain amount of Z7, that could 
be used as input for the next demand of Z3 
(not shown on the dispositive bill of materials 
drawn above). 

This results in a "chicken and egg” problem: 

• to find a sequence between the production 
tasks, it is needed to know the amounts to be 
produced, as the duration of a production task 
depends on the amount to be produced; 

• the amounts to be produced depend on stocks, 
and the stocks evolve with time during the 
planning period depending on the chosen se- 
quence of production. 


The requirement is to generate time windows for 
all finished and intermediate products appearing 
in the dispositive bill of materials, from the de- 
mands of finished products. For this, a convenient 
sequence for the production of the required fin- 
ished and intermediate products has to be found. 

The prototype has to perform backward schedul- 
'■ ing where planning starts from the finished prod- 
ucts and the allocations are made as late as 
possible. Backward scheduling in this way tends 


1. In the following, “order", “production ta*k", “demahd" will be 
used indiscriminately. 


2 Cutting the complexity 

2.1 Decomposition of the planning 
horizon into sub-periods 

lb solve this “chicken and egg” problem, a further 
approximation was introduced in the planning 
process model. This approximation divides the 
planning horizon into several “sub-periods”. This 
means that stocks are taken into account as if 
they were available only at the frontiers between 
these sub-periods. 
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In this way, it is still possible that more is pro- 
duced during a sub-period than is strictly necessary: 
some stocks created during this sub-period (because 
of minimal lot size constraints) could have been 
used to reduce some demands for the same products 
occurring later in the same sub-period. However 
these stocks are likely to be used during the next 
sub-period, as a particular product is often produced 
again several times in the year 1 . Thus stock levels 
over the whole planning horizon should remain rela- 
tively stable. 

It is not necessary to actually perform the plan- 
ning of a sub-period in order to know how much 
stocks will be available at the end: all the demands 
in this sub-period will be produced, so it is not 
needed to know the exact sequence to compute the 
global result in terms of stocks available at the end. 

It is then sufficient to: 

• group the demands into sub-periods, accord- 
ing to their due dates; 

» rearrange the demands, within each sub- 
period, taking into account stocks available at 
the end of the preceding sub-period, and 
compute the new stock levels at the end of the 
current sub-period. 

This process is repeated for each disposition 
level in turn, starting with level 0 (i.e. finished prod- 
ucts). The reason for starting with disposition 
level 0 is simply that initially, there are only 
demands for finished products, from which demands 
for intermediate products have to be successively 
derived. 

2.2 Decomposition of the problem 
according to machine groups 

The planning problem consists in making choices 
about a sequence and precise dates for all the de- 
mands to be produced. This search space is too 
wide to expect reasonable computation times. It is 
then needed to decompose the search space into 
several sub-spaces that can be treated independ- 

ently. . . 

The machine groups serves as a basis for this 

decomposition: 

• the list of machine groups is ordered accord- 
ing to dependency links, to obtain a so-called 
machine group graph (this more or less re- 
flects the fact that a machine group is allocat- 


ed to lower or higher levels of the dispositive 
bill of materials), 

• for each machine group in turn: 

* a sequence and particular dates for the 
tasks are chosen; 

* these choices are committed; 

* due dates and earliest beginning dates 2 
for tasks allocated to the remaining ma- 
chine groups are propagated. 

2.3 Cycles in the machine group 
graph 

There is a cycle in the machine group graph when, 
between two production tasks that are allocated 
to the same machine group, there exists one or 
several intermediate production tasks to be per- 
formed on other machine groups. According to the 
experts of the pharmaceutical company, this is un- 
usual, and it is acceptable in such cases if the re- 
sult is not as good. 



In this example, there is a cycle between mg2 
and mg3, because of the links between PI and Z2, 
Z2 and Z6, and Z2 and Z7. If mg2 is treated before 
mg3, the demand on Z2 coming from that on PI will 
be planned as late as possible with respect to the 
precedence constraints, which will eventually result 
in no freedom being left for the demand of PI. If 
mg3 is treated before mg2, then the demands on Z2 
and even Z3 will eventually be too constrained. 

Such cycles must be cut. The minimum number 
of links in the dispositive bill of materials that have 
to be cut in order to eliminate the cycle are marked 
(in the above example, the link Z2 ~ ► PI is cut 
rather than the links Z6 Z2 and Z7 —* Z2). 
When there is a dependency between two produc- 
tion tasks along one of these links, these tasks are 


1. Regulation* require a pharmaceutical company to hare sev- 

eral years of stock*, so external demands are not customer- 
driven. For most finished products, the yearly demand is split 
into several ones with due dates distributed over the year. 


2. The earliest beginning date of a demand is the date when all 
input products are available. 
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further constrained so that the planning freedom is 
equally shared out among these tasks. 

3 The program 


location for this product during the pre- 
ceding sub-period. 

a demand that will take some amount of 
an input product from stocks is con- 
strained to begin later than this date. 


The program has been implemented using 
Prolog III, a prolog interpreter with integrated 
constraints over rationals, booleans, and lists. 

The basic algorithm is: 

. first the machine group graph is computed 
from the dispositive bill of materials and the 
machine group allocation to products; 

• then the data structure, which is a network 
of demands linked by constraints, is con- 
structed; 

• si schedule is computed, 

• finally, the resulting plan is shown in a 
graphical form. 


The construction of the data structure and the 
planning process will now be described: 

Data structure 

The data structure is a list of demands/orders rep- 
resented each by a term: 

[ id, product, machine group, due date, 
duration, end date, dependency info ] 

It is constructed starting from the highest level 
of the dispositive bill of materials (i.e. finished prod- 
ucts) going to the lower levels. At each level, for 
each product: 

1. demands are grouped into sub-periods accord- 
ing to their due dates; 

2. for each of these sub-periods in turn: 

a. demands are rearranged according to 
minimal lot sizes constraints, residuals 
and stocks available at the beginning, 


. residuals availability constraints: the use of 
residuals is allowed only if the demand is al- 
ready constrained to begin later than the end 
date of the residuals production. 

Planning, making choices 

Even after decomposing the problem according to 
machine groups, the search space still needs to be 
reduced in order to make the program reasonably 
efficient. As it seems sensible to treat together 
mands that are close in time, sub-penods will be 
introduced again here. Choices will be committed 
after planning each sub-period. 

However this decomposition into sub-periods 
implies some additional constraints ln order to 

express these constraints, it is needed to define the 
“planning limit” for a machine group as the latest 
end date of all allocations of th lsmach ine poup ° r 
the demands of the previous sub-period^ The addi- 
tional constraints are that no allocation for the 

rent sub-period can be made before this planning 
limit (to reduce the complexity, otherwise it would 
be needed to check disjunction with allocations of 

preceding sub-periods). 

For each machine group in turn (starting from 
the machine groups allocated to the higher levels of 
the dispositive bill of materials): 

. the demands are grouped into sub-penods, ac- 
cording to their due dates; 

• for each sub-period: 

* if it is possible to find a conflict-free se- 
quence, a maximisation of the minimum 
of all end dates is performed (so that the 
whole set of production tasks is planned 


b. stocks that will be available at the end 
are computed; 

3. from all these rearranged demands (over the 
whole planning horizon), demands for inter- 
mediate products are derived, and data about 
residuals is updated. 

During the construction of this data structure, 
several kinds of constraints are enforced: 

* precedence constraints, 

• stocks availability constraints: 

* stocks of a product are considered to be 
available only after the end of the last al- 


* if no conflict-free solution exists, conflicts 
are progressively allowed but minimised. 
This minimisation has to be based on a 
conflict evaluation. However, finding a 
convenient cost function of conflicts is a 
problem in itself, and one of the objectives 
of this prototype is to experiment with 
different ones. Up to now, the implement- 
ed measure is simply a count of the 
number of days in overlaps. 

These optimisations are local to one machine 
group during one sub-period because a global opti- 
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misation would be too expensive in computation 
time. 

The resulting plan ^contains j^recise dates for each 
production task instead of just time windows, as 
was requested at the beginning. In fact, this re- 
sult can be viewed as a particular “fully instanti- 
ated” solution of the problem. In order to leave 
some freedom to the local plants, a more general 
solution could be retrieved, by deducing time win- 
dows from these precise dates and from the de- 
pendency information which was kept in the data 
structure. 

4 Computational results 

Two versions of the program exist: 

• a coarse one for getting a rough idea of the re- 
sulting plan quality allowed by a given ma- 
chine group allocation, 

* a finer (but slower) one for getting the best 
possible plan for a given machine group allo- 
cation. 

There is currently a dearth of representative 
examples (the extraction of the machine group infor- 
mation from the detailed description of each plant is 
still an open problem being tackled by people from 
the pharmaceutical company), and so no figures are 
yet available. 

However, what has been learned from the devel- 
opment of the current prototype is the adequacy of 
the CLP approach for prototyping. The CLP 
approach allowed a switch from one version of the 
algorithm to alternative ones in a very short time, 
because of the declarativity and expressiveness of 
CLP languages. 

Conclusion 

The validation of the approach described in this 
paper can only come from the experimental use of 
this prototype together with several instances of a 
local plant scheduling tool, in order to check 
whether feasible plans are obtained. Such experi- 
ments have not yet been possible because of the 
difficulty in extracting the machine group infor- 
mation from the detailed data. 

Up to now, the main interest in this work has 
been the refinement of the approach during discus- 
sions with experts from the pharmaceutical com- 
pany. These discussions were based on hypothetical 
examples and on the successive versions of the pro- 
gram which have lead to the one presented here. 

When representative examples become avail- 
able, this research will go on by using this prototype 


to experiment with different evaluation functions of 
conflicts, and to investigate about the validation of 
the resulting plan. 
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1. INTRODUCTION 

1 Over the past few years, several approaches 
to scheduling have been proposed that attempt 
to reduce tardiness and inventory costs by 
opportunistically (i.e. dynamically) combining a 
resource-centered perspective to schedule bot- 
tleneck resources, and a job-centered perspec- 
tive to schedule non-bottleneck operations on a 
job by job basis. Rather than relying on their 
initial bottleneck analysis, these schedulers 
reexamine the problem each time a resource or 
a job has been scheduled. This enables them to 
detect the emergence of new bottlenecks during 
the construction of the schedule. This ability 
has been termed opportunistic scheduling [3]. 
Nevertheless, the opportunism in these systems 
remained limited, as they required scheduling 
large resource-subproblems or large job- 
subproblems before allowing for a change in the 
scheduling perspective (i.e. before permitting a 
revision in the current scheduling strategy). 
For this reason, we actually refer to these ap- 
proaches as macro-opportunistic techniques. 

In reality, bottlenecks do not necessarily span 
over the entire scheduling horizon. Moreover 
they tend to shift before being entirely 
scheduled. A scheduler that can only schedule 
large resource subproblems will not be able to 
take advantage of these considerations. Often it 
will overconstrain its set of alternatives before 


having worked on the subproblems that will 
most critically determine the quality of the en- 
tire schedule. This in turn will often result in 
poorer solutions. A more flexible approach 
would allow to quit scheduling a resource as 
soon as another resource is identified as being 
more constraining 2 . In fact, in the presence of 
multiple bottlenecks, one can imagine a tech- 
nique that constantly shifts attention from one 
bottleneck to another rather than focusing on 
the optimization of a single bottleneck at the 
expense of others. Therefore, it seems desirable 
to investigate a more flexible approach to 
scheduling, or a micro-opportunistic approach, 
in which the evolution of bottlenecks is con- 
tinuously monitored during the construction of 
the schedule, and the problem solving effort 
constantly redirected towards the most serious 
bottleneck. In its simplest form, this micro- 
opportunistic approach results in an 
operation-centered view of scheduling, in which 
each operation is considered an independent 
decision point and can be scheduled without re- 
quiring that other operations using the same 
resource or belonging to the same job be 
scheduled at the same time. 

Section 2 describes a micro-opportunistic fac- 
tory scheduler called IVUCRO-BOSS 
(Micro-Bot tleneck Scheduling System). Section 
3 describes an empirical study that compares 


'This research was supported, in part, by the Defense 
Advanced Research Projects Agency under contract 
#F30602-88-C-000 1 , and in part by grants from McDon- 
nell Aircraft Company and Digital Equipment Corpora- 
tion. 


2 [1] describes an alternative approach in which 
resources can be resequenced to adjust For resource 
schedules built further down the road. This approach has 
been very successful at minimizing makespan. Attempts 
to generalize the procedure to account for due dates seem 
to have been less successful so far [6]. 
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MICRO-BOSS against a macro-opportunistic 
scheduler that dynamically combines both a 
resource-centered perspective and a job- 
centered perspective. A summary is provided in 
Section 4, along with a brief discussion of cur- 
rent research efforts. 

2. A MICRO-OPPORTUNISTIC 
APPROACH 

In the micro-opportunistic approach im- 
plemented in MICRO-BOSS, each operation is 
considered an independent decision point. Any 
operation can be scheduled at any time, if 
deemed appropriate by the scheduler. There is 
no obligation to simultaneously schedule other 
operations upstream or downstream within the 
same job, nor is there any obligation to schedule 
other operations competing for the same 
resource. 

MICRO-BOSS proceeds by iteratively select- 
ing an operation to be scheduled and a reser- 
vation (i.e. start time) to be assigned to that 
operation. Every time an operation is 
scheduled, a new search state is created, where 
new constraints are added to account for the 
reservation assigned to that operation. A so- 
called consistency enforcing procedure is ap- 
plied to that state, that updates the set of 
remaining possible reservations of each un- 
scheduled operation. If an unscheduled opera- 
tion is found to have no possible reservations 
left, a deadend state has been reached: the sys- 
tem needs to backtrack (i.e. it needs to undo 
some earlier reservation assignments in order 
to be able to complete the schedule). If the 
search state does not appear to be a deadend, 
the scheduler moves on and looks for a new 
operation to schedule and a reservation to as- 
sign to that operation. 

In MICRO-BOSS, search efficiency is main- 
tained at a high level by interleaving search 
with the application of consistency enforcing 
techniques and a set of look-ahead techniques 
that help decide which operation to schedule 
next (so-called operation ordering heuristic) and 
which reservation to assign to that operation 
(so-called reservation ordering heuristic). 

1. Consistency Enforcing (or 


Consistency Checking): Con- 

sistency enforcing techniques 
prune the search space by infer- 
ring new constraints resulting 
from earlier reservation assign- 
ments [2, 5], 

2. Look-ahead Analysis: A two- 

step look-ahead procedure is ap- 
plied in each search state, which 
first optimizes reservation assign- 
ments within each job, and then, 
for each resource, computes con- 
tention between jobs over time. 
Resource/time intervals where job 
contention is the highest help 
identify the critical operation to 
be scheduled next (operation or- 
dering heuristic). Reservations for 
that operation are then ranked 
according to their ability to min- 
imize the costs incurred by the 
conflicting jobs (reservation order- 
ing heuristic). By constantly 
redirecting its effort towards the 
most serious conflicts, the 
scheduler is able to build 
schedules that are closer to the 
global optimum. Simultaneously, 
because the scheduling strategy is 
aimed at reducing job contention 
as fast as possible, chances of 
backtracking tend to subside 
pretty fast too. 

The so-called opportunism in MICRO-BOSS 
results from its ability to constantly revise its 
search strategy and redirect its effort towards 
the scheduling of the operation that appears to 
be the most critical in the current search state. 
This degree of opportunism dif fers from that 
displayed by other approaches where the 
scheduling entity is an entire resource or an en- 
tire job [3], i.e. where an entire resource or an 
entire job needs to be scheduled before the 
scheduler is allowed to revise its current 
scheduling strategy. 
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3. PERFORMANCE EVALUATION 




MICRO-BOSS was compared against a 
variety of scheduling techniques, including 
popular combinations of priority dispatch rules 
and release policies suggested in the Operations 
Management literature [5]. 

This section outlines a study comparing 
MICRO-BOSS against a macro-opportunistic 
scheduler that dynamically combined both a 
resource-centered perspective and a job- 
centered perspective, like in the OPIS schedul- 
ing system [3]. However, while OPIS relies on a 
set of repair heuristics to recover from inconsis- 
tencies [4], the macro-opportunistic scheduler of 
this study was built to use the same consistency 
enforcing techniques and the same backtrack- 
ing scheme as MICRO-BOSS 3 . The macro- 
opportunistic scheduler also used the same 
demand profiles as MICRO-BOSS. When 
average demand for the most critical 
resource/time interval was above some 
threshold level (a parameter of the system that 
was empirically adjusted), the macro- 
opportunistic scheduler focused on scheduling 
the operations requiring that resource/time in- 
terval, otherwise it used a job-centered perspec- 
tive to identify a critical job and schedule some 
or all the operations in that job. Each time a 
resource/time interval or a portion of a job was 
scheduled, new demand profiles were computed 
to decide which scheduling perspective to use 
next. Additional details on the implementation 
of the macro-opportunistic scheduler can be 
found in [5]. 

In order to compare the two schedulers, a set 
of 80 scheduling problems was randomly 
generated to cover a wide variety of scheduling 
conditions: tight/loose average due dates, 

narrow/wide due date ranges, one or two bot- 
tleneck machines. Each problem involved 20 
jobs and 5 resources for a total of 100 opera- 
tions (see [5] for further details). 


3 An alternative would have been to implement a varia- 
tion of MICRO-BOSS using the same repair heuristics as 
OPIS. Besides being quite time-consuming to implement, 

such a comparison would have been affected by the 
quality of the specific repair heuristics currently im- 
plemented in the OPIS scheduler. 



Figure 3-1: Tardiness performance of 
MICRO-BOSS and the 
macro-opportunistic scheduler 
on eight different problem sets. 



Figure 3-2: Flowtime performance of 
MICRO-BOSS and the 
macro-opportunistic scheduler 
on eight different problem sets. 


Figures 3-1, 3-2 and 3-3 summarize the 
results of the comparison between MICRO- 
BOSS and the macro-opportunistic scheduler 4 . 
Hie macro-opportunistic scheduler was consis- 
tently outperformed by MICRO-BOSS (under 
all eight scheduling conditions) both with 


4 The results presented in this section correspond to the 
69 experiments (out of 80) that were each solved in less 
than 1,000 search states by the macro-opportunistic 
scheduler. 
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Figure 3-3: In-system time performance of 
MICRO-BOSS and the 
macro-opportunistic scheduler 
on eight different problem sets. 

respect to tardiness, flowtime (i.e. work-in- 
process) and in-system time (i.e. total inventory, 
including finished-goods inventory). More 
generally, these results indicate that highly con- 
tended resource l time intervals can be very 
dynamic, and that it is critical to constantly fol- 
low their evolution in order to produce quality 
schedules. 

In most problems, MICRO-BOSS achieved a 
search efficiency of 100% (computed as the ratio 
of the number of operations to be scheduled 
over the number of search states that were 
visited), and required about 10 minutes of CPU 
time to schedule each problem. The current sys- 
tem is written in Knowledge Craft, a frame- 
based representation language built on top of 
Common Lisp, and runs on a DECstation 5000. 

4. CONCLUSIONS 

In this paper, a micro-opportunistic approach 
to factory scheduling was described that closely 
monitors the evolution of bottlenecks during the 
construction of the schedule, and continuously 
redirects search towards the bottleneck that ap- 
pears to be most critical. This approach differs 
from earlier opportunistic approaches, such as 
the one described in [3], as it does not require 
scheduling large resource subproblems or large 
job subproblems before revising the current 


scheduling strategy. This micro-opportunistic 
approach has been implemented in the context 
of the MICRO-BOSS factory scheduling system. 
A study comparing MICRO-BOSS against a 
macro-opportunistic scheduler suggests that the 
additional flexibility of the micro-opportunistic 
approach to scheduling generally yields impor- 
tant reductions in both tardiness and inventory. 

Current research efforts include: 

^Xdaptation of MICRO-BOSS to 
deal with sequence-dependent 
setups \ v e*. 

• Development of micro- 
opportunistic reactive scheduling 
techniques that will enable the sys- 
tem to patch the schedule in the 
presence of contingencies such as 
machine breakdowns, raw 
materials arriving late, job cancela- 
tions, etc. 


APPENDIX: PROBLEM SETS 


Problem Sets 

Number 
of Bottlenecks 

Avg. 

Due Date 

Due Date 
Range 

Problem 

Set 

1 

loose 

wide 

1 

1 

loose 

narrow 

2 

1 

tight 

wide 

3 

1 

tight 

narrow 

4 

2 

loose 

wide 

5 

2 

loose 

narrow 

6 

2 

tight 

wide 

7 

2 

tight 

narrow 

• 8 
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Abstract 

We present a heuristics-based approach to deep 
space mission scheduling which is modeled on 
the approach used by expert human schedulers 
in producing schedules for planetary encoun- 
ters. New chronological evaluation techniques 
are used to focus the search by using infor- 
mation gained during the scheduling process 
to locate, classify, and resolve regions of con- 
flict. Our approach is based on the assumption 
that during the construction of a schedule there 
exist several disjunct temporal regions where 
the demand for one resource type or a single 
temporal constraint dominates (bottleneck re- 
gions). If the scheduler can identify these re- 
gions and classify them based on their domi- 
nant constraint, then the scheduler can select 
the scheduling heuristic. 

1 Introduction 

Scheduling science experiments for such projects as 
Viking, Voyager, and Spacelab consumes a large amount 
of time and manpower. Whenever the Voyager space- 
craft encounters a planet, the science experiments must 
be preplanned and ready to execute. This is a difficult 
scheduling problem due to the number and complexity 
of the experiments and the extremely limited resources 
of a spacecraft. 

Since very few opportunities for space science exist, 
the major goal of mission scheduling is to maximize the 
number of science experiments that can be performed 
using the limited resources of the spacecraft. The total 
amount of requested experiments can be several times 
the amount that the project can accomplish. 

Not only are schedules oversubscribed, they are also 
dynamic. Although the Voyager spacecraft was built and 
launched years ago, the flight rules governing the use 
of the spacecraft have changed. As the scientists learn 
more about their objectives, the experiment requests are 
updated. Thus, the mission schedule is a dynamic entity. 

*This research was done at the Jet Propulsion Labora- 
tory, California Institute of Technology, and was sponsored 
through an agreement with the National Aeronautics and 
Space Administration. 


The Jet Propulsion Laboratory has performed mission 
scheduling for many years with a variety of deep space 
flight projects. The effort in scheduling an entire project 
such as Voyager can be measured in mancenturies. Be- 
cause of this huge cost, JPL has been researching ad- 
vanced software scheduling systems for several years (e.g. 
Deviser, Plan-It, Switch, Ralph, OMP). 

Our current research, the Operations Mission Plan- 
ner (OMP), is centered on minimally disruptive (non- 
nervous) replanning and the use of heuristics to limit 
the scheduler’s search space. This paper addresses some 
of the problems pertinent to mission scheduling. It then 
defines iterative refinement, one of the basic design goals 
of our current research. This work has been greatly in- 
fluenced by discussions with and the observations of the 
expert mission schedulers for the Viking, Voyager, and 
Spacelab projects. 

2 Definitions 

2.1 Resource/ St ate 

A resource/state (here after shorten to resource) tracks 
how a variable describing a state of the system changes 
through time and the steps which presently reserve this 
resource. An example is a pooled resource which tracks 
how many pieces of equipment out of a limited pool is 
being used at any moment in time. Another example is 
the direction of an antenna which is a continuous-state 
resource. 

There are five fundamental types of resources: ca- 
pacity, consumable renewable, continuous-state, and 
discrete-state [Starbird, 1987]. A capacity resource is ba- 
sically a pooled resource but can have non-integer value 
and may have a time varying initial capacity.. Steps allo- 
cate a amount of the resource for their duration and then 
free up the resource for other activities. A consumable 
resource is one for which there is a limited supply, and 
once it is used by a step, it is no longer available (e.g. 
spacecraft fuel). A renewable is a generalization of a 
consumable, where the resource can be replenished (e.g. 
storage tape; it is used up during recording, and ’’replen- 
ished” during playback). A state resource represents a 
resource whose state (configuration, position, etc.) must 
be a certain value in order to support an activity. A 
continuous- state resource is one in which the state of 
the resource can best be described by a continuous vari- 
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able (e.g. the direction that an antenna is pointing). 
A discrete-state resources, on the other hand, are repre- 
sented by discrete values (e.g. on/off, low-gain /medium- 
gain /high- gain). 

Most domain resources can either be directly mapped 
into these resource types or be modeled by combining 
these type of fundamental resources to form a special 
metar resource. A ground based Deep Space Network An- 
tenna could bejnodeled as a meta-resource which com- 
bines two continuous- states and a renewable resource. 
The two continous-states would model the azimuth and 
declination while the renewable would model the num- 
ber of times the antenna cables are wrapped wound the 
antenna pedestal. 

While the four fundamental types of resources can be 
used to model most of the resources we have encoun- 
tered there exist a domain specific resources which could 
not be easily modeled. An example is the Voyager tape 
recorder which is a four track tack wire tape recorder. 
To schedule the tape recorder the schedulers build tape 
ihaps of what data is at what physical location on which 
track. This information is used to determine the order 
in which data can be removed and how long it takes to 
position the tape head to the beginning of a particular 
data track. 

Associated with each type of resource is its definition 
of conflict. A conflict for a capacity resource occurs if 
the system reserves more then the limit of the pool at 
any moment in time. The resource is in conflict at the 
temporal interval for which a oversubscription occurs. A 
discrete-state is in conflict if either a step "reserves” a 
state that is not compatible with the state of the resource 
during the duration of the step or if the resource changes 
states without having an appropriate state changing step 
occurring. 

2*2 Step/Activity 

A step is a temporal interval which "reserve” resources 
where the meaning of reserve depends on the type of 
resource. While the resources model the state of the 
system over time steps model changes or constraints on 
the system. Along with resource reservations a step 
can contain constraints that either directly limit the 
range of choices possible in scheduling a step or links 
a step to other steps. The most common type of link- 
ing constraints are temporal predecessor and successor 
relations. 

An activity is a set of steps and a set of constraints 
that link the steps together. The temporal constraints 
are the "glue^ that bind the steps into a logical unit. 
The most common type of temporal linkage is the pre- 
decessor and successor relations. Along with the steps 
and constraints between the steps, an activity includes 
constraints that act on upon all the steps within an ac- 
tivity. This includes any global temporal windows and 
other global scheduling preferences like a priority for the 
request. 

The users views an activity as the "primitive” action 
that must be scheduled to satisfy a user scheduling re- 
quest. When a user issues a "request” the system finds 
the one or more activities that satisfy the request. The 


scheduler heuristically selects one of the activities and 
schedules the entire activity as a logical unit. Unlike 
resources the scheduler does not violate the constraints 
within an activity. 

Since the activities interact only through the resource 
timelines, in some sense the activities are independent. 
It is possible to modify a previously schedule activity 
without backtracking or updating any other scheduled 
activity. Modifying a previously scheduled activity may 
cause some resource conflicts, but at certain stages of the 
scheduling process that is acceptable. The scheduler hats 
the ability to note the conflicts for resolution at latter 
stages in the processing. 

3 Focused Iterative Refinement 

3.1 Expert Iterative Refinement 

Iterative refinement is a technique used by expert space- 
craft schedulers. The expert user first lays out the highly 
constrained activities over which he has little or no con- 
trol. This forms a background against which the rest 
of the scheduling is done. The expert user then places 
the activities which impact large portions of the sched- 
ule. These may, for example, be a series of activities 
that have to be performed at exactly one-hour intervals 
over a large portion of the schedule. Any changes to 
this type of activity would cause changes to most of the 
schedule. If the scheduler gets stuck trying to place such 
an activity, he may elect to move it, but only as a last 
resort. Next, the expert user positions the high-priority 
activities, minimizing the number of conflicts. Finally, 
to complete the initial loading process, the expert user 
places the remaining activities on the schedule. If, at 
this point, some of the lower-priority activities do not fit 
easily, the expert user may simply ignore them. 

After the loading process is done, the schedule is 
80sense that most activities are in their final position on 
the schedule), although some resource contentions may 
still exist. The expert user has only spent about 20user 
will spend the remaining time trying to fit a few more 
activities into the schedule and trying to resolve resource 
contentions. 

Up to this point in the scheduling process the sched- 
uler has been task oriented [Smith and Ow, 1985]. Now 
the scheduler becomes resource oriented. The expert 
user focuses on the activities which are causing resource 
contentions on a particular resource and in a particular 
time region. After this area is fixed the expert user moves 
to another. Using this type of planning, the expert user 
iterates over and over again on the schedule, each time 
refining it a little more. After each pass through the 
schedule, the scheduler is willing to do a deeper search 
on any single activity because the total number of activ- 
ities needing to be searched will decrease. 

By focusing on just one area at a time the expert user 
may fix a portion of the schedule just to cause conflicts 
when the next portion of the schedule is processed. Af- 
ter several iterations, a small set of activities will cir- 
culate through the problem areas of the schedule. In 
this stage of scheduling, the expert user once again be- 
comes task oriented. The expert user focuses on this 


small set of h&rd-to-place activities and performs the 
deepest search. The expert user addresses any chain 
reactions resulting from moving a specific activity. In 
Voyager scheduling this reasoning recurses about three 
levels down. In SpaceLab science scheduling the depth 
cut off is about four levels down. It is important to re- 
alize, however, that at this point the expert user has a 
small list of activities to try. The scheduler also restricts 
the impacted activities to those that seem flexible. 

In the final stage of processing, the expert user looks 
for under-utilized areas of the schedule. The expert user 
checks the list of unscheduled activities looking for an 
activity that could use these resources. This unsched- 
uled activity will, most likely, not fit directly into the 
schedule without causing some conflicts. Otherwise, the 
activity would have been scheduled earlier in the pro- 
cess. The scheduler tries to adjust some of the activities 
in the under-utilized areas in order to make room for the 
unscheduled activity. This may involve a series of shifts, 
but since both the activity and the under-utilized areas 
have been identified, it is a tightly focused search. 

The schedule is then evaluated by the mission scien- 
tists for its total science return. The scientists negotiate 
with one another and with the scheduling team about 
which activities to include in the final sequence. The re- 
sults of the negotiations must be reflected in the sched- 
ule. Therefore, the evaluation process following the gen- 
eration of the initial schedule often results in requests to 
change the schedule, and hence the requirement for the 
replanning capability discussed earlier. 

3.1.1 Phases of Iterative Refinement 

Iterative planning consists a series of techniques. Each 
technique is responsible for a different aspect of the over- 
all planning process. The first of these techniques roughs 
out the plan and identifies areas of high resource-conflict. 
The later techniques use the knowledge of the resource 
conflicts to refine the plan and solve many of the sched- 
ule problems. The final techniques try to solve the last 
of the conflicts and "optimize” the plan. 

The OMP Load Phase is responsible for drafting an 
initial schedule. During this phase, the scheduler focuses 
on the requested activities, fitting them into the schedule 
with minimal concern for conflicts and levels of oversub- 
scription. 

During the Resource Centered Phase, OMP becomes 
resource oriented [Smith and Ow, 1985]. The scheduler 
focuses upon a resource region which contains conflicts 
and uses quick and simple techniques to fix these re- 
gions before processing another resource. It is during 
this phase that the bulk of the schedule is roughed out. 

By focusing on just one resource region at a time the 
scheduler may fix one portion of the schedule but cre- 
ate additional conflicts in other regions. The scheduler 
discovers the bottlenecks by tracking these interactions 
between the separate regions. Once a bottleneck has 
been identified, it is classified and OMP attempts to re- 
solve that bottleneck using techniques specialized for the 
type of bottleneck. 

Once the conflict regions of the schedule have been 
resolved (which, since this is an oversubscribed domain 


will involve deleting some activities from the schedule), 
OMP takes another look at the high priority activities 
which have been deleted from the schedule and tries to 
fit them in. At this point, OMP will perform its deep- 
est search in an effort to schedule just one more activity 
(extremely important in a domain such as deep space 
mission scheduling where opportunities to perform in- 
terplanetary experiments are rare). This phase is called 
the Optimization , although it doesn’t produce a truly 
optimal schedule as would be defined in an operations re- 
search sense. Rather, it refers to fitting in additional ac- 
tivities after a conflict-free schedule has been produced. 
According to Spacelab scheduling experts, an optimal 
schedule is one where no one can suggest an improve- 
ment [Japp, 1986]. 

By specializing the planning techniques, each tech- 
nique can be made more efficient. For example, the 
first techniques will use shallow searches over a broad 
spectrum of activities. Later techniques will use deeper 
searches but the search will only be applied to a limited 
number of activities. They will use knowledge about 
the particular schedule (i.e. the current resource con- 
flicts, which activities have changed most often in the 
scheduling process) to constrain the search space. The 
techniques will employ either a shallow and broad search 
or a deep and narrow search. If a planner must perform 
a broad and deep search, it will not be able compute the 
schedule in any reasonable time. 

3.1.2 Self- Reflective Iterative Refinement 

The basic concept of self-reflective search is focusing 
the search by using knowledge gained from monitoring 
the search process. The OMP architecture, operating 
as outlined in the previous section, provides the mecha- 
nisms for supporting self-reflective search: the chronolo- 
gies gather the raw information, the assessment heuris- 
tics analyze the information and feed the results to the 
control heuristics which focus the dispatch heuristics. 

During the scheduling process, OMP keeps a chronol- 
ogy [Biefeld and Cooper, 1989] of the effort expended 
to resolve resource conflicts. In OMP, the chronologies 
are composed of a set of course grain resource timelines 
which record the scheduling effort level associated with 
a given region of the schedule, one measure of which is 
the number of times the scheduler attempts to resolve 
conflicts in that rejpon. 

During the resource centered phases, OMP focuses on 
a temporal interval within a given resource that is in 
conflict. Simple heuristics (which either change the re- 
source used by an activity or temporally shift an activ- 
ity out of the focus region [Biefeld and Cooper, 1991]) 
are used to reduce the level conflict in the focus region. 
The chronologies keep track of the effect of these actions 
within the region and on other regions which are changed 
as a result of the scheduling actions. 

The system first attempts to find a set of resource as- 
signments which reduces the total amount of conflict in 
the entire schedule. If the system can not lower the total 
conflict then it will increase the effort level for the focus 
region. The system retries the search, again attempting 
to reduce the conflict level in the region of focus, how- 
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ever this time it can increase the conflict level in other 
temporal regions for which the effort level is less than 
the focus region’s effort level. 

The above process will eventually cause OMP to cycle 
through the same regions. When the effort level for these 
regions exceeds the preset threshold, OMP exits the re- 
source centered phase and begins the bottleneck cen- 
tered phase. The assessment heuristics search through 
the chronologies and find the regions that have recently 
been raised to a high effort level. These regions are then 
collected into a bottleneck. The assessment heuristics 
then classify the bottleneck depending on its temporal 
size and its degree of oversubscription. 

The current assessments heuristics in OMP distinguish 
bottlenecks by: 1) the amount of subscription compared 
to the bottleneck capacity; 2) the temporal extent of the 
bottleneck regions; and 3) the number of resources the 
bottleneck spans. Using these ratings the assessment 
heuristics classify the bottlenecks as either: 1) largely 
oversubscribed; 2) close to capacity but large in extent; 
or 3) close to theoretical capacity and small in extent. 

If a bottleneck is largely oversubscribed then OMP’s 
control heuristics will delete the low priority activities 
from the bottleneck region until the demand is only 
slightly larger then the capacity of the bottleneck. If 
a bottleneck is close to capacity but large in extent the 
control heuristics will split the bottleneck into several 
smaller regions. The first step is to distribute the task- 
ing uniformly across the bottleneck and to reduce the 
demand slightly by shrinking the duration of the activi- 
ties. The control heuristics will then focus on the smaller 
regions and use dispatch heuristics that emphasize local 
modifications over the global modifications used in the 
Resource Centered Phase. During this processing the 
assessment heuristics closely monitor the chronologies to 
identify small bottleneck regions. OMP processes each 
of the small bottlenecks as it locates them. 

When processing a small bottleneck OMP uses it’s 
most complicated heuristics. They use localized modifi- 
cations to position one more activity onto the schedule. 
If the region in conflict is temporally small, the heuristics 
will either try to clip some activity whose start or end 
time is near the conflict, or the heuristics will split some 
activity into two separate activities with a gap equal to 
the conflict duration. If the conflict region is slightly 
larger, the heuristics clip and form gaps in a series of 
activities and align these gaps in such a manner as to 
reduce the conflict over the focus region. 

Some heuristics, such as those for antenna handoff, 
are domain specific. A antenna handoff is when an ac- 
tivity splits its requirement for an antenna between two 
or more antenna resources. In the OMP demonstration 
domain, an activity may use one antenna for the first 
part and a second antenna for the second part but there 
must be a period of overlap during which it is using both 
antennas. In the OMP demonstration domain, if a bot- 
tleneck either spans two antennas or the temporal re- 
gions on the two antennas are near but do not completely 
overlay, then a antenna handoff may be practical. The 
dispatch heuristics attempt to split the activity into two 
activities and assign the antennas and temporal overlap 


to reduce resource contention. 

This is an example of not only domain specific ways 
of expanding an activity but also where domain specific 
heuristics are needed to suggest when and how to try a 
particular activity expansion. Since the durations of the 
handoff overlap and the duration that an activity must 
spend on any single antenna is relatively small compared 
to the entire duration of an activity, the total number of 
ways an activity can be sliced up using antenna hand- 
offs is quite large and in most cases not very useful. By 
identifying the bottleneck regions and then using domain 
specific heuristics to find particular patterns in the bot- 
tleneck regions the search process can be restricted, while 
still finding most cases were there special configuration 
tricks are useful. 

4 Summary 

This iterative pieinning approach to scheduling arose 
from attempts to heuristically control the search space 
of mission scheduling. The source of the heuristics were 
the human schedulers of Voyager, Viking, and SpaceLab 
who provided information on the stages of the schedul- 
ing process. Earlier stages are concerned with ” roughing 
out” the schedule, placing most of the tasks, and identi- 
fying the trouble areas. Later stages then use scheduling 
heuristics to refine the existing schedule. 

Most of these heuristics assume that the scheduler 
knows which resources are the bottlenecks and which 
tasks are causing the most difficulty for the scheduler. 
The best way to identify these critical resources and 
tasks is from the schedule produced by the earlier stages. 
In order to know what to try next one must already know 
what the schedule will be like. 

Iterative planning assumes that the information 
gained by earlier techniques can be used by the later 
techniques to constrain the search space. Iterative plan- 
ning also assumes that the schedule will not be changed 
dramatically by the later techniques. These assumptions 
seem to hold for the mission scheduling domain, which 
is extremely under- constrained. There exist many pos- 
sible schedules for a single set of requested tasks. Two 
different human schedulers will produce two very differ- 
ent but equally acceptable schedules, given the same set 
of requested tasks. If, however, one human scheduler 
must modify another person’s schedule, the basic struc- 
ture of the schedule will not be modified. Therefore, 
expert schedulers normally perform non-nervous replan- 
ning. 
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1. Introduction 

Although there has been a lot of progress in knowledge- 
based scheduling [5,4], there is still a need for schedule 
improvement and repair through interaction with a human 
scheduler. There are several reasons for this. First, a user’s 
preferences on the schedule are context dependent (e.g., 
may depend on the state of the scheduling environment at a 
particular time). Also, interactions among preferences and 
effective tradeoff very often depend on the particular 
schedule produced. This means that generally a user of the 
scheduling system can’t fully specify his/her preferences a 
priori before getting the scheduling results from the system. 
By looking over the obtained schedule results, the user of- 
ten thinks of additional preferences. Consider, for example 
a situation where a human scheduler does not like to use 
MACHINE-A which is substitutable for MACHINE-B but 
is of lower quality than MACHINE-B for processing 
ORDER-X. The reason high quality results are desired is 
that ORDER-X belongs to a quite important client. Sup- 
pose, however, that the schedule indicates that ORDER-X 
is tardy by an amount above an acceptable tardiness 
threshold due to demands on MACHINE-B (by orders more 
important than ORDER-X). Then, the human scheduler 
may decide to use the less preferable machine, MACHINE- 
A for the less important order, ORDER-X. If the tardiness 
was below the threshold, he/she may prefer to allow a tardy 
order. It is very difficult to elicit this type of preference and 
preference thresholds from the human scheduler independ- 
ent of the presence of a particular context 
The second reason interactive schedule repair is desirable 
is that it is impossible for any given knowledge based 
scheduling model to include all the constraints that may be 
relevant Current advanced scheduling systems can exploit 
very complicated models to represent the factory^ orders 
and user’s preferences. But no matter how richly the model 
is constructed, there are always additional factors which 
may influence the schedule but had not been represented in 
the model. For example, for a certain foundry it may be 
good to decrease usage of a sand casting machine during 
the summer, because the combination of heat and humidity 
of the weather may make it slower than usual. But how 
should the model of the scheduling system represent the 


season, weather or humidity? And isn’t it necessary for the 
model to represent time of the day, strength of wind or 
health of a machine operator and so on? [2]. Nevertheless 
these factors, that an experienced human scheduler learns to 
take into consideration, could have a big influence on 
schedule quality but it is very difficult to represent in a 
principled manner so they can be used by an automated 
scheduling system. 

The third reason interactive schedule repair is desirable is 
that factories are dynamic environments. Unexpected 
events, such as operator absence, power failure and 
machine breakdowns frequently happen. Therefore, it is 
necessary for the scheduling system to adapt to the events 
in the factory environment as soon as possible by reactively 
repairing the existing schedule. Although initial progress 
has been made in automatic schedule repair [3], human in- 
tervention may be necessary as a result of the reasons given 
(context dependent user preferences, and difficulty of 
representing all relevant constraints). 

Another consequence of the above is that local repair 
rather than rescheduling is more desirable, since re- 
scheduling will suffer from the same ills as the initial 
scheduling. In addition, it is in general desirable [3] to min- 
imize disruption to the shop floor. If re-scheduling from the 
point of failure is attempted, the new schedule may be dras- 
tically different from the original schedule, thus necessitat- 
ing disruption of the work flow in the shop, and new work 
allocation. The new schedule, moreover may solve the cur- 
rent problem but introduce new problems that have to be 
solved. 

One extremely beneficial side effect of interactive 
schedule repair is the insight that the user obtains into 
his/her scheduling preferences and their context of ap- 
plicability. The process of interactive repair requires the 
human scheduler to analyze the current problem, repair it 
by clarifying or modifying his/her preferences and finally 
evaluate the result This gives the human scheduler good 
opportunities to understand his/her criteria in diverse situa- 
tions. So later when he/she encounters a problem that is 
similar to a previous one, he/she can be reminded of the 
applicable previous repair and re-use it in the current situa- 
tion. 
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1.1. Why case-based repair? 

Case-based Reasoning (CBR) is a recent AI problem 
solving paradigm [1]. A CBR system tries to solve a 
problem by (1) retrieving the most sim ilar case with the 
current problem from its case base, (2) modifying it to 
adapt to the current situation and (3) applying it to the cur- 
rent problem. At the end of problem solving, the new 
solved problem is stored as a new case in the case memory. 
As a computational model the first feature of CBR is its 
method of knowledge acquisition. In CBR the unit of 
knowledge is the case, which is an experience encountered 
during problem solving. This makes it easier to articulate, 
examine and evaluate the knowledge. The second feature is 
its learning capability. A CBR system can remember its 
performance and modify its behavior to avoid repeating 
prior mistakes. The third feature is its adaptive power. By 
reasoning from analogy with the past experiences, a CBR 
system should be able to construct solutions to novel 
problems. These features make CBR very attractive for in- 
teractive schedule repair. 

Because a case describes a particular specific experience, 
the factors that were deemed relevant to this experience can 
be recorded in the case. This description fully captures the 
dependencies among features and their context. So if a 
similar situation is encountered, the system can re-use the 
repairing method which is stored in the retrieved case. In 
addition, a case serves as a knowledge structuring 
mechanism so that all relevant factors are local to a case 
rather than distributed through the system (as happens with 
rule based systems). Even when the result of applying the 
repairing method of the retrieved case turns out to be 
failure, if the user can explain the failure, then the system 
can create a new case based upon this failure experience 
and store it as a new case along with the associated ex- 
planation. Thus, as the case base is enriched with successful 
and failed experiences, the system becomes more robust for 
various type of schedule defects that would have been dif- 
ficult to predict in advance. This enables the replacement of 
expert users with novices that rely on the system’s ex- 
periences. 

2. Case-based Interactive Scheduler (CABINS) 

Based upon the above discussion, we are developing the 
Case-based Interactive Scheduler (CABINS) whose goal is 
to support interactive schedule repair. A CABINS user is 
envisioned to be a person who is responsible for making 
schedules in advance of production. In making an initial 
schedule, the user may be assisted by an automated 
scheduling system. If the user identifies undesirable fea- 
tures of the current schedule, he/she uses CABINS for 
schedule repair, so as to improve the current schedule. 
CABINS finds defects in scheduling results and repairs 
them by patching locally or modifying part of its model 
(resources, orders, shifts and user’s preferences). 


11. System Architecture 
After the initial schedule is made, it is examined by the 
user and the defect detector (a rule-based system) to find 
undesirable parts in the existing schedule. If some defects 
are detected, the information about the defects are passed to 
the repairer. If local repairing is determined to be feasible 
by the repairer, resource reservations in the current 
schedule are directly modified or canceled by the repairer 
and die scheduler is asked to re-schedule the conflicting 
operations whose reservations were canceled. When local 
repair turns out to be impossible, the repairer modifies the 
scheduling model and re-scheduling is attempted based on 
the modified model. The overall goal of CABINS is to 
make repairs as cheap as possible trying at the same time to 
minimize interfering side effects of these repairs on the cur- 
rent schedule. Figure 2-1 depicts the architecture of 
CABINS. 



Figure 2-1: Architecture of CABINS 


2*2. Schedule Repairing Process 

The processing of CABINS has four stages: 

• defect detection 

• defect selection 

• selection of repair strategy 

• selection of repair tactics 

Currendy defect detection and defect selection are per- 
formed by the user who finds the most important defect and 
identifies the features associated with the defect. These fea- 
tures are used as indices into the case memory to find 
similar past defects. Out of the retrieved similar past 
defects,” the critical is selected. To determine defect 

criticality, the system uses the cost of repairing the defect as 
a measure: the lower the repair cost, the less critical the 
defect. Low repair cost is usually associated with local 
patching whereas high cost means that more changes are 
made to the overall schedule. So, beginning with the lowest 
cost repair is a good heuristic since the defect can be poten- 
tially fixedfcheaply. 

CABINS uses two level of repairs: repair strategies and 
repair tactics. A repair strategy is associated^ with a par- 
ticular high level description of classes of defects. Each 
repair strategy has a variety of repair tactics associated with 
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it. The repair tactics are appropriate for particular 
specializations of the defect classes. We have identified two 
general types of repair strategies: local patching and model 
modification. 

To select a strategy for repairing important defects, 
CABINS looks for the most similar case to the current 
situation in the case base and selects the same strategy 
which succeeded in the past case. The system has several 
alternative strategies for each defect and one of them is 
selected based on the feature similarity of the current situa- 
tion and the past experience. Some of the features that we 
are currently using for case retrieval are various defect 
types, such as order tardiness and various schedule charac- 
teristics, such as schedule tightness, inter-order slack, and 
machine idle time. For example, if the type of defect is 
"tardy order”, there are seven repair strategies: 

1. Reduce the slack between operations in the tardy 
order 

2. Reduce the idle-time of resources needed by opera- 
tions in the tardy order 

3. Relax due-date constraint of orders (the tardy order 
or interfering orders) 

4. Relax release-date constraint of orders (the tardy or- 
der or interfering orders) 

5. Reduce the shop load 

6. Increase shifts 

7. Increase resource capacity. 

The first two strategies belong to the general category 
"local patching" and the rest to the category "model 
modification". 

In general, we have presented the repair strategies in or- 
der of expensiveness (from the cheaper -strategy 1 to most 
expensive -strategy 7). For tardiness repair, the dis- 
criminating feature between selecting cases with repair 
strategies in classes 1 to 2 and selecting cases with repair 
strategies 3 to 7 is the tightness of the current schedule. If 
the current schedule is not very tight (i.e., there are a lot of 
idle intervals on resources needed by operations of the tardy 
order), CABINS will select cases where tardiness was 
repaired by local patching. Whether cases with repair- 
strategy- 1 or repair- strategy-2 will be selected depends on 
whether, beside enough idle interval, there is also slack be- 
tween adjacent operations of the lardy order. If there are, 
then cases where strategy- 1 was used will be selected. Tac- 
tics associated with strategy-2 could be to move every 
operation of the tardy order upstream (left shifting) on the 
time line if enough idle interval is available for the opera- 
tion. 

If the current schedule is tight, then cases that prescribe 
model modification rather than local patching will be 
retrieved. If there are no discriminating features to deter- 
mine the applicability of strategies 3 to 7, CABINS uses the 
default ordering: use strategies in ascending cost. The 
cheapest model modification is relaxing due-date con- 
straints of the tardy order or interfering orders (strategy-3). 
This is cheap since it is easily accomplished and has no side 
effects on the shop floor environment. On the other hand. 


reducing the factory load (strategy-5) (e.g., by subcontract- 
ing orders) and re-scheduling is in general more expensive 
than relaxing due dates of interfering orders because one 
must determine the orders to be subcontracted out, price of 
subcontracting, possible delays etc. An additional concern 
is that the resulting schedule might not be entirely satis- 
factory and may need to be repaired anew. Similarly, 
strategies 6 and 7 are increasingly expensive, since ad- 
ditional investments in paying overtime or buying new 
machines are needed. 

Although strategy-3 is the cheapest of the repair 
strategies of type "model modification", it may not always 
be desirable. To determine applicability of strategy-3, 
CABINS retrieves cases where application of strategy-3 has 
failed. If other features of the current situation match fea- 
tures of the past failures of strategy-3 (e.g., the tardy order 
has a stiff penalty for tardiness), then CABINS is warned 
that strategy-3 is not applicable. Similarly, if there are no 
discriminating features to distinguish among the application 
of strategies 4 to 7, retrieval of previous cases where the 
strategy under consideration has failed gives the system ad- 
ditional discriminating information. Thus, CABINS uses 
the default ordering of repair strategies as well as successful 
case application as necessary conditions of the applicability 
of particular repairs; it uses past failures as sufficiency con- 
ditions. As more cases are encountered, both the necessary 
and sufficiency conditions are refined. Therefore, it is 
hoped that CABINS can improve its performance over 
time. 

For each repair strategy, there could be a variety of repair 
tactics that are applicable. For repairing order tardiness, 
there is a variety of appropriate tactics for local patching. 
Below, we present some of these tactics. 

1. left-shift on same resource: move the operation as 
much to the left as possible, while maintaining the 
amount of disruptions as small as possible. 

2. left-shift on substitutable resource: if the operation 
that is desired to be moved has a substitutable 
resource, then move the operation as much to the 
left as possible, while maintaining the amount of 
disruptions as small as possible. 

3. swap on same resource: find another operation 
which is to the left of the operation to be moved on 
the same resource and whose duration is ap- 
proximately equal to the duration of the current 
operation and swap the two operations. 

4. swap on substitutable resource: if the operation that 
is desired to be moved has a substitutable resource, 
then find another operation which is to the left of the 
operation to be moved on the substitutable resource 
and whose duration is approximately equal to the 
duration of the current operation and swap the two 

operations. 

The last two tactics may result in tardiness of other or- 
ders but this may be allowable. 

For model modification, possibly applicable tactics along 
with the associated repair strategy are: 
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1 . relax -due-date-of-tardy-order (strategy-3) 

2. find-most-interfering-order with the current tardy 
order and make it tardy (strategy-3) 

3. relax-release-date-of-tardy -order (strategy-4) 

4. find-most-interfering-order with the current tardy 
order and make it start earlier (strategy-4) 

5. subcontract-least-profitable-order to create more 
slack (strategy-5) 

6. subcontract-most-interfering-order to create more 
slack (strategy-5) 

7. overtime-work on weekday (2 hours) (strategy-6) 

8. overtime-work on weekend (8 hours) (strategy-6) 

9. increase-capacity-of-most-critical-resource 
(strategy-7) 

10. capacity-of-substitutable-resource-of-most-critical- 
resource (strategy-7) 

Each retrieved case has been repaired by possibly using a 
combination of repair strategies and tactics. Upon recog- 
nition of similarities in schedule defects and defect context, 
the appropriate repair plan could be applied. If the applica- 
tion of a repair step leads to failure, the user is asked to 
supply a possible explanation of the failure. The failure is 
then stored in memory so it can be retrieved and help the 
user avoid similar failures in the future. 

3. Example 

In this chapter we explain how CABINS works by using 
a simple example. In the example we make a schedule of 4 
orders on 5 resources. Each order has a client, fixed release- 
date and fixed due-date. Every order is composed of 5 
operations (ope-1 to ope-5), which should be ordered in that 
order. Each operation has fixed duration and requires one 
resource which may or may not have a substitutable 
resource. The detail specifications of the example problem 
are depicted in figure 3-1. In Figure 3-2 we show the result 
of the original scheduling. Each rectangle represents the 
reservation of each operation over the time-interval on the 
machine. The small number inside each rectangle shows the 
order to which the operation belongs. In scheduling the 4 
orders, the scheduler failed to meet the due-date of order-3 
by 130. (The due-date of order-3 is 790, while order-3 is 
scheduled to finish on 920.) Suppose that the client of 
order-3 has had the late shipment of his orders several 
times, s/he is sure to cancel her/his contract as a result of 
our more tardy shipment. Therefore, finding and fixing this 
situation is critical. A human scheduler at the factory tries 
to fix this problem by consulting with CABINS. 

First, CABINS considers the current problem as a case 
by compiling the current scheduling results with respect to 
the tardiness of order-3. A human scheduler gives ad- 
ditional contextual information to it if s/he finds it’s neces- 
sary or helpful for finding the solution of the current 
problem. The vocabulary of this information is maintained 
by CABINS and a human scheduler can update it by 
adding/deleting terms. Figure 3-3 shows the contents of 
this example problem case. 

Then, CABINS tries to retrieve the case most similar 
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Figure 3-1: Problem Specifications 



Figure 3-2: Initial Schedule 



Figure 3-3: Current Problem Case 


cases to the current problem case from its case-base library. 
The retrieved case includes not only the problem situation 
description but also repairs and repair outcomes. For repair 
strategy selection, every solution includes the information 
of the selected strategy, the result of applying the strategy 
and the explanation of why it succeeded or failed. The ex- 
planation of the solution outcome is added to the case by a 
human scheduler only when s/he thinks it is necessary for 
credit or blame assignment of the selected strategy. Figure 
3-4 depicts the retrieved case to solve this example 
problem. 

After display of the retrieved cases, a human scheduler 
examines whether s/he can apply the same solution method 
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to the current problem. Even when the result of the solution 
in the retrieved case was failure, the solution may be worth 
trying if the explanation of failure given in the previous 
case does not hold in the current situation. On the other 
hand, a human scheduler should also check the validity of 
the explanation of a successful previous solution before s/he 
applies it to the current problem. In this example, even 
though the first solution failed when it was applied in the 
precedent case, a human scheduler can try to apply it, be- 
cause the explanation of the failure given CEvery good sub- 
contractor is busy") is apparently related to the description 
of the context of the problem ("Industry in Boom"). There- 
fore the explanation is not necessarily true in the current 
situation which doesn’t share the same context Note that 
those judgments are done by a human scheduler. However, 
by retrieving and displaying previous similar cases, 
CABINS gives her/him useful information to help making 
her/his decision. Moreover, the greater the number of new 
cases that are added into the case-base library, the more 
likely CABINS is to retrieve the case which is close enough 
to the current problem. Therefore, it becomes progressively 
easier through CBR to decide whether the solution of the 
retrieved case is applicable or not. 

After determining the solution method, a human 
scheduler can execute it by interacting with the scheduling 
system. Figure 3-5 depicts the result of rescheduling 
order-3 after subcontracting the least profitable order 
(order- 1) in this example. It shows that order-3 meets its 
due-date, i.e. the repair was successful. 



Figure 3-5: Repaired Schedule 


4. Concluding Remarks 

In this paper we discuss the need for interactive factory 
schedule repair and improvement, and identify case-based 
reasoning (CBR) as an appropriate methodology. Case 
based reasoning is the problem solving paradigm that relies 
on a memory for past problem solving experiences (cases) 
to guide current problem solving. Cases similar to the cur- 
rent case are retrieved from the case memory, and 
similarities and differences of the current case with past 
cases are identified. Then a best case is selected and its 
repair plan is adapted to fit the current problem description. 
If a repair solution fails, an explanation for the failure is 
Stored along with thecase in memory, so that the user can 
avoid repeating similar failures in the future. 

So far we have identified a number of repair strategies 
and tactics for factory scheduling and have implemented a 
part of our approach in a prototype system, called CABINS. 
As a future work, we are going to scale up CABINS to 
evaluate its usefulness in a real manufacturing environment 
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Abstract 

The Autonomous Power System (APS) project at 
the NASA Lewis Research Center is designed to 
demonstrate the applications of integrated intelligent 
diagnosis, control and scheduling techniques to space 
power distribution systems. The project consists of three 
elements: the Autonomous Power Expert System (APEX) 
for Fault Diagnosis, Isolation, and Recovery (FDIR); the 
Autonomous Intelligent Power Scheduler (AIPS) to 
efficiently assign activities start times and resources; and 
power hardware (Brassboard) to emulate a space-based 
power system. 

The AIPS scheduler has been tested within the 
APS system. This scheduler is able to efficiently assign 
available power to the requesting activities and share this 
information with other software agents within the APS 
system in order to implement the generated schedule. The 
AIPS scheduler is also able to cooperatively recover from 
fault situations by rescheduling the affected loads on the 
Brassboard in conjunction with the APEX FDIR system. 

AIPS served as a learning tool and an initial 
scheduling testbed for the integration of FDIR and 
automated scheduling systems. Many lessons were 
learned from the AIPS scheduler and are now being 
integrated into a new scheduler called SCRAP (Scheduler 
for Continuous Resource Allocation and P lannin g) This 
paper will serve three purposes: an overview of the AIPS 
implementation, lessons learned from the AIPS scheduler, 
and a brief section on how these lessons are being applied 
to foe new SCRAP scheduler. 


1. Introduction and Motivation 

Future NASA spacecraft and planetary surface 
installations will require larger and more sophisticated 
infrastructure systems and living environments. Such 
systems will consist of dozens of resources and hundreds 
of attached loads. The electrical power system on the 


Space Station Freedom, a L unar base, or Martian base 
represents a critical portion of such a system. The APS 
project explores intelligent hardware and software 
architectures for efficient system operation and scheduling 
of an electrical power system [Ringer 199 lj. 

1.1 The Need For (Automated) Scheduling 

Onboard a complex spacecraft many activities 
must be performed, each competing for a multitude of 
temporal positions and limited resources. A scheduler 
must assign start times to each activity without violating 
any resource or temporal constraints. The resources 
onboard such a spacecraft will be vastly oversubscribed, 
having many times more resource requests than av ailab le 
resources. This makes it a paramount objective to 
efficiently utilize the available resources in order to 
complete as many activities as possi ble. ■ _ _ _ 

Current NASA space-based systems rely on 
ground-based human-intensive scheduling methods. 
Humans provide foe main scheduling intelligence for 
constructing schedules. These schedules are then 
transmitted to foe spacecraft to be executed. If the 
scheduling expertise and computers are ground-based, 
every anomaly that occurs onboard foe spacecraft that 
incurs a schedule modification would cause significant 
time delays and efficiency losses. With the advent of 
more complex space-based systems such as foe Space 
Station Freedom and beyond, a more efficient automated 
scheduling paradigm is necessary [Britt 1988]. 

1.2 The APS Project Scheduling Goals 

The goal of the APS project is automated 
scheduling for space systems with proof-of-concept 
demonstrations on a power system testbed. In this process 
only the high level goals of foe system are stated by the 
human operators, that is, which activities should be 
performed. This information is taken and the scheduler 
attains foe goal of activities executed. The scheduler must 
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not only know how to generate the schedule, but must also 
know how to implement the schedule, and how to recover 
from system or load induced deviations in the schedule. 


2. AIPS Implementation 

Since scheduling cannot take place in a vacuum, 
the scheduler must be able to interact with other agents as 
well as cope with many operational concerns. The 
scheduler must be able to generate an initial schedule, it 
must have domain specific knowledge of bow to 
implement the schedule, it must be able to reactively 
modify the schedule in the case that the assumed 
information of the state of the system changes, and it must 
be able to do this within metric time constraints. 

2.1 What is being scheduled 

The APS Brassboard is a power system testbed 
that contains a set of power supplies, switchgear, and 
loads that emulate a space-based power system. This 
hardware is controlled by a set of embedded controllers 
capable of configuring the state of the Brassboard. These 
controllers are then used to configure the Brassboard to 
supply power to the loads designated by the scheduler. 
Figure 1 shows the current configuration of the APS 
Brassboard. RBI's and RPC's are remote controlled 
switches and an L represents a load attached to the system. 

The loads attached to the Brassboard are resistive 
load banks. In order to more closely emulate a space- 
based power system each load is given a set of attributes 
resembling those of a space-based system. Each activity 
(load) has a time varying profile of power demand, earliest 
start time and latest completion time constraints, priority, 
and temporal placement preference. 


Source 1 Source 2 


Figure 1 Brassboard Power System Configuration 


2.2 Cooperation Between AIPS and APEX 

AIPS is responsible for assigning the power 
requesting activities attached to the Brassboard temporal 
positions and resources without overallocating the 
available power. APEX is responsible for the 
implementation of the schedule generated by AIPS. In 
order to adequately model the interaction between APEX 
and AIPS, a set of protocols was developed to 
communicate different scheduling and rescheduling 
procedures. Protocols were developed to generate an 
initial schedule and modify executing schedules. Figure 
2 shows a graphical representation of a schedule generated 
by AIPS. A chart showing the interaction between the 
three portions of the APS project is given in Figure 3. 

2.3 __ Scheduling Methods Used 

Two modes of schedule generation are needed for 
any integrated scheduling system. The ability to generate 
an initial schedule and the ability to modify (reschedule) 
an already executing schedule in the case of an anomaly. 
In the former case, a metric amount of time is allocated to 
the scheduler after which a solution must be returned. In 
the latter case, the rescheduling results are usually needed 
as soon as possible. 



Figure 2 Representative Schedule Generated by AIPS 


The AIPS scheduler has two modes of schedule 
generation used for scheduling and rescheduling. The 
scheduling engine is an incremental scheduler that uses a 
set of activity selection and placement heuristics [Sadeh 
1989]. These heuristics are used to construct a schedule 
by taking each activity one by one, and determining where 
to place the activity on the timeline. These heuristics also 
form the basis of the rescheduling engine. 

When the scheduler is given more time, it will 
use the same basic heuristics along with a Monte-Carlo 
type optimization method to generate multiple schedules 





based on the heuristics. Since the heuristics use local 
goodness information, they do riot produce globally good 
schedules. Small perturbations to these heuristic decisions 
will often improve the efficiency of the generated 
schedule. Each schedule is rated based on a goodness 
rating and when time to generate a schedule has run out, 
the best schedule (that has been saved in memory) is 
returned. With a relatively huge state space of solutions 
this method works quite well probing many portions of the 
state space that look promising based on the heuristics. 



Figure 3 APS Component Functionality 


Rescheduling must also be accomplished "non- 
nervously", that is, with as little deviation to the original 
schedule as possible [Biefeld 1990, Zweben 1990], In 
systems with human interaction the ori ginal schedule 
should be followed as closely as possible in order to not 
disturb the humans interacting with the system. To 
accomplish non-nervous rescheduling, AIPS uses a set of 
heuristics that judge the amount of perturbation caused by 
a schedule modification versus the change of goodness of 
the new schedule. 


3. Lessons Learned 


Lessons were learned from the design of the 
scheduler, implementing a scheduler in a real system, and 
integrating scheduling with an FDIR system. Some of the 
lessons learned represented shortfalls in the original AIPS 
scheduler while others represented ideas for the 
improvement of the overall efficiency of the scheduling 
system. 

3.1 Retrospective 

Many of the concepts implemented in the AIPS 
scheduler worked quite well. Time was broken down into 
smaller scheduling horizons in order to make the problem 
solution feasible. Priorities were used to delineate 


between the relative value of activities. Time was 
partitioned at a granularity of five minutes. This was a 
reasonable simplification since the time for APEX and the 
Brassboard to be configured was on the order of one 
minute. The ability to schedule within metric time 
constraints was incorporated. A graphical interface was 
available for both schedule display and human-scheduler 
interaction. 

The largest assumption made about the 
environment was that all temporal durations and resource 
requests are exact. In a real-life situation, if an activity 
requests 100 watts for one hour the probability of the 
activity using a constant 100 watts or lasting exactly one 
hour is quite small. The problems incurred may include 
undervoltage/overcurrent conditions caused by higher than 
expected demands as well as propagation of temporal 
constraints among activities caused by an extension of an 
activity's duration. The need for some type of temporal or 
resource padding is necessary. This padding decreases 
schedule efficiency although it may improve overall 
implemented schedule efficiency since the schedule will 
not have to be modified as often with the padding added. 

3.2 Perspective 


Much was learned about scheduling, but even 
more was learned about implementing a schedule in an 
automated domain. The whole object of scheduling is to 
produce the best overall system efficiency. In order to 
increase the efficiency of the implemented schedule, most 
new ideas point to the need for the ability for real-time 
reaction in the scheduler [Johnston 1989]. Here are three 
examples. 

Conventional schedulers use temporal padding to 
increase the probability of executing a schedule. 
Temporal uncertainties cause the forward propagation of 
predecessor/successor constraints and resource availability. 
If activities are padded, and this padding is not used, it is 
wasted. It may be possible, however, to assign this 
temporal position/resource to another activity. This would 
entail moving another activity forward in time to fill the 
temporal position/resource left unused by the previous 
activity. This demonstrates a need for reaction in the 
scheduler. 

Suppose a 500 watt cooling fan operates only 
when the experiment temperature rises above a certain 
threshold. This may only operate 10% of the time (10% 
duty cycle). How can the resources be allocated to 
prevent oversubscriptions? If 500 watts are continuously 
allocated 90% of this energy will be wasted (of course, a 
conflict free schedule is guaranteed). Energy balancing 
between multiple duty cycle activities can be used, but 
problems arise if all these activities turn on at the same 
time. Reaction is needed to delay some of these events if 
they desire to consume power when it is not immediately 
available. In addition, there is the possibility of 
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performing energy balancing in the power system domain. 
With energy balancing however, it is necessary to use a 
storage type resource such as a battery. 

When using reaction, think about the 
"moveability" of an activity. In a Space Station domain, 
a dishwashing activity is much more moveable than a 
medical experiment using two crew members and various 
ground-based experts. The dishwashing activity has very 
few attached dependencies while the medical experiment 
would require the movement of many human interactors. 
The dishwashing activity is easier to move and a small 
temporal position change will not affect it as long as the 
dishes are washed before the next meal. This information 
can be used to make reactive modifications to the schedule 
without impacting the humans who will have to interact 
with the system. 

The ideas of temporal padding usage, duty cycle 
balancing, and activity moveability will allow for more 
efficient use of limited resources. Of course, a scheduler 
(and testbed architecture) that allows these ideas to be 
implemented remains to be built and tested. The next 
section will briefly describe this new scheduler. 


4. Implementing the Lessons Learned 

The SCRAP scheduler is currently under 
development. General improvements in the representation 
of the SCRAP scheduler include multiple resources, 
multiple resource types (capacity, consumable, and 
storage), one second time granularity, activities broken 
into tasks, and multiple levels of schedule abstraction. 
Since the previous section showed a need for reaction, a 
scheduling paradigm that makes reaction easier would be 
beneficial. 

4.1 Prediction vs. Reaction 

Two general categories can be delineated in 
scheduling: predictive and reactive systems. Predictive 
scheduling allows the efficient allocation of available 
resources to activities by generating schedules based on 
predicted knowledge of the activity and resource states. 
This type of scheduling works well in static domains but 
is often hard to implement and less efficient in complex, 
uncertain, and dynamic domains. Reaction provides easier 
implementation in dynamic domains, but sacrifices 
resource usage efficiency caused by the lack of knowledge 
used to generate schedules. 

In most real world problems a combination of 
static and dynamic domains exist. For example, a 
completely reactive scheduler might have no information 
on predicted resource demands of an activity, while a 
completely predictive scheduler would assume exact 
temporal durations and resource requests. Usually, a 
combination of these methods are used with a predicted 


resource level that provides an allowance for deviations 
from that level. This would point to the use of a 
combination of reaction and prediction. All schedulers 
that operate in a real domain actually combine the two, 
but the idea of SCRAP is to provide a framework that 
allows these ideas to be implemented efficiently. 

4.2 How to Combine Prediction and Reaction 

Even though building an initial schedule is 
computationally intense, the need to continuously modify 
the schedule during execution is even more difficult 
because of the tighter time constraints in the rescheduling 
domain. When rescheduling, all temporal and resource 
constraints propagate forward causing even more conflicts 
in the schedule, also known as the ripple effect. 
Propagating temporal and resource constraints during a 
reschedule clobbers previously computed future portions 
of the schedule. If rescheduling occurs often, the entire 
precomputed schedule may be recomputed by the 
rescheduling engine. This is an extreme case but proves 
the point that it may not be necessary to construct the 
initial schedule with a great level of detail. Therefore it 
may be wise to schedule far term activities with less effort 
or detail than near term activities. In the SCRAP 
scheduler this is accomplished by using multiple levels of 
abstraction when scheduling activities. Further into the 
future the schedule is constructed abstractly, while nearer 
to the execution time more precision is used. Also, more 
in-depth scheduling methods are used for times nearer to 
the execution time than for times further into the future. 



Multiple abstractions based on temporal distance 
from the execution time will allow for more efficient 
forward temporal propagation of constraints in the 
schedule since less information is used for the future 
portions of the schedule. The future portions of the 
abstractly generated schedule serve as a partially computed 
schedule when it comes time to actually schedule at a 
more precise level. The scheduling timeline can be looked 
at as a rolling horizon, with the future coming closer to 
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the present as time ticks during execution. 

Figure 4 graphically shows the general idea of 
SCRAP. The timeline moves in conjunction with the 
movement of "real" time. Time "now" is the current 
execution time of the schedule. Time "infinity" is some 
time very far in the future. The gantt chart shows I-beams 
at different levels of scheduling abstraction. T he s olid 
lines are precisely scheduled, the dashed lines are 
scheduled at a medium abstraction, while the dotted lines 
are abstractly scheduled. Resource oversubscriptions are 
allowed in the future since the schedule in those areas has 
not been computed more abstractly. Nearer to the time of 
execution, more scheduling effort and precision is used 
and these resource conflicts will be eliminated. 

Many of the reactive situations stated in the 
lessons learned section can be more easily implemented 
using the SCRAP paradigm. In an automated domain the 
scheduler has much more control over the executing 
schedule. This control along with the ability to efficiently 
modify the schedule during execution will allow for an 
overall implemented schedule efficiency increase. 

5. Conclusion 

The Autonomous Power System project at the 
NASA Lewis Research Center is an ongoing effort to 
demonstrate the use of knowledge-based diagnosis and 
scheduling software in advanced space-based electrical 
power systems. The APS project has completed one 
development iteration. A scheduling system was 
developed for the APS project and integrated with an 
FDIR system and hardware. The original AIPS scheduler 
was successful as a learning tool and a new improved 
scheduler is being developed. Many new ideas for 
increasing the implemented schedule efficiency will be 
realized using the SCRAP paradigm. The SCRAP 
scheduling paradigm will allow for more efficient use of 
the available resources. 
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Introduction 

Texas Instruments (TI) is currently contracted by the 
Air Force Wright Laboratory and the Defense Ad- 
vanced Research Projects Agency (DARPA) to develop 
the next generation flexible semiconductor wafer fab- 
rication system called Microelectronics Manufacturing 
Science & Technology (MMST). Several revolutionary 
concepts are being pioneered on MMST including new 
single-wafer rapid thermal processes, in-situ sensors, 
cluster equipment, and advanced Computer Integrated 
Manufacturing (CIM) software* The objective of the 
project is to develop a manufacturing system capa- 
ble of achieving an order of magnitude improvement 
in almost all aspects of wafer fabrication [1]. TI was 
awarded the contract in October, 1988, and will com- 
plete development with a fabrication facility demon- 
stration in April, 1993. 

An important part of MMST is development of the 
CIM environment responsible for coordinating all parts 
of the system. The CIM architecture being developed 
is based on a distributed object oriented framework 
made of several cooperating subsystems. The soft- 
ware subsystems include: Process Control for dynamic 
control of factory processes; Modular Processing Sys- 
tem for controlling the processing equipment; Generic 
Equipment Model which provides an interface between 
processing equipment and the rest of the factory; Spec- 
ification System which maintains factory documents 
and product specifications; Simulator for modelling the 
factory for analysis purposes; Scheduler for scheduling 
work on the factory floor; and the Planner for planning 
and monitoring of orders within the factory. 

This paper first outlines the division of responsibil- 
ity between the Planner, Scheduler, and Simulator sub- 
systems. It then describes the approach to incremental 
planning and the way in which uncertainty is modelled 
within the plan representation. Finally, current status 
and initial results are described. 

Planner/Scheduler Division of 
Responsibility 

One role of the Planner is to plan and predict work 
completion dates, given a required confidence level, set 


of plan goals and the current state of the factory. This 
requires that the plan representation model factory re- 
source utilization over time, and that the plan be con- 
tinually updated to reflect unexpected events such as 
machine failure. This role is not provided by the Sched- 
uler, which performs more locally based decision mak- 
ing. 

As part of this role, the Planner is able to warn the 
user of the impact of unexpected events. For example, 
the Planner can determine whether work completion 
dates are slipping, well in advance of their quoted de- 
livery dates. The user can also be warned of any work 
which has been automatically replanned due to unex- 
pected events, so that they may request changes to the 
plan if required. Automatic replanning of work will re- 
main an option to be invoked if desired by the user. 

The ability to request plan changes is another key 
Planner role which is not provided by the Scheduler. 
’What-if’ plan changes refer to requests such as putting 
a machine on hold or introduction of new work. 

Finally the Planner constrains work release into the 
factory, based on the current plan being executed. This 
is important since early release of work carries the 
penalty of increased WIP and early completion of work 
is undesirable. The high level plan representation does 
not allow the Planner to determine the precise mo- 
ment for work release, which may be based on low 
level factory data such as machine queue sizes. This 
is an important role for the Scheduler, since work re- 
leased early will only increase WIP by placing work on 
a queue. Work release is accomplished by the Sched- 
uler requesting more work from the Planner, with the 
Planner satisfying the request as best as possible given 
the work planned for release over the next chosen time 
interval. 

Another role of the Scheduler is to make sequencing 
decisions for work on the factory floor, based on de- 
tails such as queue sizes, machine setups, and so forth. 
Although such decisions may be based on currently 
planned ship dates, this service cannot be provided by 
the Planner (which does not distinguish between iden- 
tical resources in the plan representation). Finally, the 
Scheduler is responsible for tracking work in process. 
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- The Planner influences the schedule being executed 
by constraining work release and predicting work com- 
pletion dates, which may be used in Scheduler dispatch 
decisions. However, work released into the factory can- 
not be directly influenced by the Planner. The Sched- 
uler provides important feedback to the Planner by 
tracking work in process. This can be used to update 
cycle time estimates used by the Planner, and to warn 
of tardy work which may cause replanning. 

Planner/Simulator Division of 
Responsibility 

Both the Planner and Simulator systems provide the 
user with the ability to determine the consequences of 
’what-if ’ requests. However, the allowed requests differ 
fundamentally between the Planner and Simulator. 

Planner ’what-if’ requests may be made on a single 
plan only, and result in incrementally updating the ex- 
isting plan to satisfy the request. Typically, the exist- 
ing plan reflects the current state of the factory. Rapid 
feedback is required, since the requests may refer to the 
effect of putting a machine down in the near future for 
maintenance, or the effect of introducing a new hot lot 
onto the factory floor. These requests must be rapidly 
evaluated if a manager is to fully benefit, since they 
may require immediate attention. The ability to have 
multiple ’what-if’ plans open simultaneously will also 
be important if possible plan options are to be com- 
pared. 

In contrast to this, Simulator ’what-if’ requests are 
typically performed by running a suite of simulations, 
using factory conditions possibly selected at random 
from a set of work release or machine failure distribu- 
tions. Feedback is not required immediately since sim- 
ulation results typically refer to changes which are not 
immediately put into practice. Example requests may 
include the effect of introducing new machines into the 
factory, or re-training several of the operators. 

The Planner system may interact with the Simulator 
in two distinct modes. First, by providing a static work 
release plan, generated using some initial factory sta- 
tus, which provides the Simulator with a work release 
time table. This is particularly important for verifying 
the plan model and algorithms, since simulated work 
completion should match plan predictions if the Plan- 
ner is correctly predicting processing capacity. Second, 
by providing a dynamic release plan, which is updated 
in response to simulated events (such as machine fail- 
ure) during simulation execution. This is important for 
verifying Planner response times, which must remain 
small if the Planner is to be truly ’reactive’. 

Approach to Incremental Planning 

A plan representation has been chosen which models 
the manufacturing environment in enough detail to 
achieve the planning functions, while allowing incre- 
mental updates due to replanning. The following sec- 


tion outlines the representation, along with the search 
algorithm used to generate aud update plans. 

Modelling the Plan 

The plan representation is based on the processing ca- 
pacity of resource groups within the factory, divided 
into contiguous time intervals. Each resource group 
has an associated set of processing capabilities which 
every member of the group is able to perform. Since a 
single semiconductor manufacturing machine may per- 
form several different processes, a machine may be a 
member of several different resource groups. Each re- 
source group is represented over contiguous time inter- 
vals, where the planned processing commitment and 
remaining capacity is recorded. 

The plan representation does not distinguish which 
resource, within a resource group, is planned to pro- 
cess a particular piece of work represented within a 
plan. The representation simply commits processing 
time for the whole resource group to a particular piece 
of work. Furthermore, the plan representation does 
not sequence processing within each time interval, only 
between time intervals. In this way, the level of detail 
modelled by the plan is a function of both resource 
groups and time interval sixes. If resource groups con- 
tained only one resource, and all time intervals were 
shorter than the shortest processing step, the plan rep- 
resentation would reduce to a Gantt chart describing 
the processing schedule for each resource. If, on the 
other hand, the entire plan were covered within a sin- 
gle time interval, the representation would reduce to 
the model frequently used for planning within semi- 
conductor manufacturing [2]. The ’time-phased’ rep- 
resentation outlined above lies somewhere between the 
two extremes. 

The plan representation must accurately reflect fac- 
tory capacity, projected forward from the current clock 
time. To ensure this, all planned processing for the ear- 
liest time interval is removed from the plan representa- 
tion when the clock time exceeds the time interval up- 
per bound. Planned processing is then compared with 
the current state of the factory (via the WIP tracking 
system) and the system user is warned of any work 
which appears tardy on the factory floor. Finally, the 
processing capacity of resource groups within the first 
plan time interval reduce linearly with time, to reflect 
the constantly increasing clock time. 

The Planning Algorithm 

The planning algorithm is divided into two parts, that 
of determining the sequence of work to be planned 
(given its due-date, customer priority, etc), and incor- 
porating the required processing into the plan repre- 
sentation (given the current resource group commit- 
ments, type of planning requested, and constraints 
imposed on which time intervals processing may be 
planned for). Planning may use the existing plan rep- 
resentation as a starting point, or some user defined 
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variation if multiple ’what-if’ plans are to be explored. 

Deciding the sequence of work to be planned ul- 
timately determines the overall product mix, and is 
determined by an ordered list of goals in which the 
first unsatisfied plan goal is used to sequence work for 
planning. The ordered goal list may be thought of as 
defining the Planner ’strategy’. Each goal sequences 
work using its associated heuristic, which is designed 
to guide plan generation in favor of satisfying the goal. 
All goals have numerical values, which must be met by 
the plan if the goal is to be satisfied. Once a goal is 
satisfied, processing moves to the next unsatisfied goal. 
By ’interleaving’ similar goals in the ordered list, the 
Planner strategy can be used to satisfy several differ- 
ent goals, while ensuring that the plan never deviates 
much from satisfying any one goal [3]. 

Once work has been sequenced for planning, it must 
be incorporated into the time-phased plan representa- 
tion. The resources required for each processing step 
must be committed over some time interval so that no 
resource group is overutilized and all constraints on 
processing are satisfied. Plan independent constraints, 
such as processing times and required resource groups, 
are determined by querying the Specification system. 
Within these constraints, the planning search algo- 
rithm determines precisely in which time interval to 
commit resource groups for each processing step. 

The planning search algorithm uses a work repre- 
sentation in which wafer processing is divided into dis- 
crete segments, where each segment represents process- 
ing on resources which may be completed within one 
time interval of the plan representation. Division of 
wafer processing into segments is performed by calcu- 
lating which segment each processing step would lie 
in if processing were distributed evenly over the en- 
tire wafer cycle time. Since the wafer cycle time is 
greater than the minimum theoretical processing time, 
such a representation accounts for the expected queue 
time during wafer processing. Each search operation 
either inserts or removes segments from the plan repre- 
sentation, terminating when all required segments for 
processing work have been inserted, or when no further 
processing capacity remains. 

The search algorithm uses a modified beam search 
with chronological back-tracking. Maximum beam 
width is determined by the ratio of measured wafer 
cycle time to minimum theoretical cycle time, since 
the greater the ratio, the greater the choice of time 
intervals for planning each processing segment. The 
search space is further reduced by constraining the 
beam width to increase linearly with search depth. 
One advantage of this is that solutions which appear 
unpromising at an early stage in the search are quickly 
discarded, whereas those which appear more promis- 
ing are more thoroughly searched. Another advantage 
is that ’disjoint’ plan representations, in which no re- 
sources may be available for an extended period of time 
due to factory shut-down, do not prevent new work 


from being planned, as long as sufficient processing ca- 
pacity exists while the factory is operational. 

Replanning due to unexpected resource failure re- 
quires reasoning at both the goal list and the search 
algorithm level. To ensure that resource groups are not 
overutilized in the plan representation when a resource 
goes down, currently planned work must be sequenced 
for replanning. This is performed by removing work 
until resource utilization levels are not exceeded, and 
then replanning this work to be released at a later date. 

Results 

Table 1 illustrates performance when using this algo- 
rithm to plan new work into an existing plan. The 
table shows the fraction of successful search nodes (for 
which a processing segment was successfully inserted 
into the plan representation), failed nodes (for which 
there was not enough processing capacity in the at- 
tempted time interval), and backtracked nodes. The 
results illustrate that even for a highly utilized factory 
the search required to plan new work, for which there is 
processing capacity available, is not prohibitive. Fur- 
thermore the percentage of backtracked nodes does not 
continue to increase with committed utilization. In a 
semiconductor fabrication facility an average of 80% 
utilization across all machines is considered very high. 
The results in this case assume that human operators 
are not a bottleneck resource. 


Tablel: 


Committed 

Utilization 

Percent 

Successful 

Node 

Percent 

Failed 

Node 

Percent 

Backtracked 

Node 

Percent 

| m 

100% 

~Wo 

Wo — 

20% 

100% 

0% 

0% 

30% 

47% 

40% 

13% 

40% 

44% 

44% 

12% 

50% 

36% 

50% 

14% 

60% 

35% 

52% 

13% 

70% 

32% 

56% 

12% 

80% 

30% 

58% 

12% 


Approach to Modelling Uncertainty 
The plan representation must be able to model the un- 
certainty inherent in work cycle-times, since such cycle- 
times often form the best available data for planning. 
The following section outlines the approach taken to 
representing uncertainty in the planning process. 

Domain Uncertainty 

Two areas of uncertainty are tackled by the Planner, 
both corresponding to data which is represented by a 
probability distribution. The first is wafer yield, which 
is recorded as the probability of manufacturing n good 
chips given the starting number. The second is cycle 
time, which is recorded as the probability of completing 
all manufacturing steps on a wafer in a given time. 
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This section outlines how cycle time distributions are 
used within the Planner. 

The objective of the Planner is to predict work com- 
pletion dates to within some given confidence, which 
may be used to negotiate with customers. For example, 
an order may be represented within the plan so that it 
completes processing on Friday to within a 50% confi- 
dence level, but on the following Monday to within an 
80% confidence level. 

Modelling Uncertainty 

Uncertainty is modelled within the Planner by reinter- 
preting the plan representation in terms of fussy sets 
(4]. Resource group utilisation for a given piece of work 
has a degree of membership within each time interval, 
which reflects the expected utilisation of resources for 
this work during the time interval. For example, the 
total cycle "time distribution for wafer processing may 
be interpreted as the probability distribution for com- 
pleting the final processing step at a given time. This 
can be modelled within the j>lan representation by as- 
signing degrees of membership between time intervals 
to match the given probability distribution for the fi- 
nal processing step. The advantage gained by this in- 
terpretation is two-fold. First, computation on fussy 
sets is much less expensive than on probability dis- 
tributions. Second, cycle time uncertainty within the 
time-phased representation means that resources com- 
mitted to processing a given set of wafer steps within 
one time interval will very likely process some of those 
steps within other time intervals. This closely matches 
the concept of membership degree within fuzzy set the- 
ory. 

To enable the Planner to reason at this level of de- 
tail, knowledge of the total processing cycle time dis- 
tribution is required, as well as some estimate of the 
distributions required to complete each time interval's 
worth of processing. Intermediate processing steps for 
which data is recorded in semiconductor manufactur- 
ing are traditionally referred to as ’log-points’. If log- 
point data were available for processing steps within 
each Planner time interval, this data could be used to 
model the distributions for required processing over all 
time intervals. However, this log-point data may not 
be available for all processing steps, only the final cycle 
time. For this reason, the Planner uses an algorithm 
to estimate log-point cycle times, given the find cycle- 
time which is available as a distribution. 

The algorithm attempts to decompose the final cy- 
cle time probability distribution into cycle time distri- 
butions for each successive time interval throughout a 
wafer’s processing. This is done so that: 

• Interval cycle time distribution variance increases 
with successive intervals, to reflect increasing future 
uncertainty. 

• Interval cycle time variance is bounded by the final 
cycle time variance. 


• The final computed interval cycle time distribution 

matches the input cycle time distribution. 

The algorithm represents distributions using fuzzy 
numbers and performs all calculations using fuzzy 
arithmetic. T?EIs approach is based on the job shop 
scheduling system FSS [5] which also uses fuzzy arith- 
metic to model increasing uncertainty in generating fu- 
ture schedules. A key advantage with this approach is 
that calculations on distributions can be performed ex- 
tremely rapidly. The algorithm has been tested against 
simulated results, as described in the ne xt section. 

Once time Interval cycle time distributions have been 
calculated for a given wafer processing route, they are 
used to ’fuzzify’ the resources committed to processing 
steps during each time interval of the plan representa- 
tion. This is achieved by using the fuzzification opera- 
tor (defined for fuzzy set theory) and results in resource 
utilization being ’smeared out’ within the plan repre- 
sentation. This reflects the uncertainty in the time at 
which planned processing will actually take place in 
the factory. 

Once work has been planned for a wafer with a given 
processing route, the final cycle time distribution is 
used to quote the completion date to within a given 
confidence level. For example, if 50% of the final time 
interval processing has been planned to complete by 
Friday, the wafer may be quoted to complete on Friday 
with a 50% confidence level. In fact, the confidence 
level associated with any delivery date may be quoted. 

Finally, measured cycle time distributions provide 
one important method for feedback to the Planner 
from the outside world. Cycle time distributions may 
be updated incrementally as wafers complete process- 
ing for each type of manufactured technology. Further- 
more, since cycle times are closely related to WIP and 
product mix, distributions used for planning should be 
chosen to reflect current conditions. However, plan- 
ning work in semiconductor manufacturing has shown 
the difficulty in predicting cycle times up-front, which 
are highly sensitive to conditions such as resource sta- 
tus and WIP levels. 

Results 

Table 2 illustrates the cycle time mean and variance, 
for part of a processing sequence completing during 
a given time interval, calculated using simulation and 
the proposed fuzzy arithmetic algorithm. The simu- 
lated CT mean and variance were calculated by per- 
forming a series of simulations, forward in time, based 
on known time interval cycle time distributions. The 
resulting final cycle time distribution (at time inter- 
val number 5) was then plugged into the algorithm to 
generate the set of estimated intermediate time inter- 
val cycle time distributions. The algorithm estimated 
time interval distributions were then compared with 
the simulated distributions by measuring their mean 
and variance. Time units are measured in numbers 
of time intervals. Agreement between simulated and 
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fuzzy means remains close, while agreement between 
simulated and fuzzy variance improves over several 
time intervals. Agreement improves as CT variance 
increases due to the greater number of members in the 
fuzzy number used to represent the distribution. We 
intend to explore several possible variations on the al- 
gorithm in an attempt to improve agreement. 


Table2: 


Time 

Interval 

Simulated 

Mean 

Fuzzy 

Mean 

Simulated 

Variance 

Fuzzy 

Variance 

i 

l.n 

1.00 

0.10 

0.00 

2 

2.21 

2.04 

0.20 

0.04 

3 

3.30 

3.10 

0.28 

0.16 

4 

4.40 

4.07 

0.37 

0.37 

5 

5.48 

5.48 

0.45 

0.45 


Current Status 

A prototype CIM system was built as one of the first 
tasks of the CIM program. This helped with the overall 
system design, as well as provide a platform in which 
to plug prototype subsystems and get feedback from 
potential users. However, only small parts of each sub- 
system had been designed at this stage. 

All CIM subsystems have now been designed and 
documented, and are currently being implemented in 
Smalltalk. The MMST Planner is currently about 25% 
of the way through the development phase. Interfaces 
between subsystems have not yet been completed, so 
many of the results shown above have relied on ’stub- 
bing’ subsystem functionality external to the Planner. 
Functionality has been stubbed to match the expected 
external system performance as closely as possible, and 
is based on a detailed scenario analysis for MMST [6]. 
In particular, wafer processing requirements and re- 
sources have been chosen to reflect those described in 
the analysis. 

The Planner mechanism that requires the most de- 
velopment is the ’what-if’ capability. Several design 
approaches have been documented, although determin- 
ing the best approach (for example, in terms of speed 
of response) will require experimental measurements 
which may only be obtained by implementation. 

Finally, full CIM installation and integration within 
a TI fabrication facility remains as the final stage in 
the MMST program. 

Conclusion 

A reactive planning system for semiconductor wafer 
fabrication has been designed and partially imple- 
mented, as part of the MMST program, jointly funded 
by TI, Air Force Wright Laboratory and DARPA. The 
planning system has been designed to maintain a plan 
which is constantly up to date with the factory envi- 
ronment, and which can reason with uncertain data 
such as processing cycle time distributions. The plan- 
ning algorithm generates plans using a variation on the 


traditional beam search, and models uncertainty using 
a fuzzy set approach. Initial results indicate that the 
system is able to incorporate new work into an exist- 
ing plan without incurring a large amount of compu- 
tationally expensive backtracking. However, further 
work will be required to verify plan results in an ex- 
isting wafer fabrication environment, and to integrate 
the Planner with the rest of MMST. 
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Abstract 

Mathematical- analytical methods as used in 
Operations Research approaches are often in- 
sufficient for scheduling problems. This is due 
to three reasons: The combinatorial complex- 
ity of the search space, conflicting objectives 
for production optimization, and the uncer- 
tainty in the production process. Knowledge- 
based techniques, especially approximate rea- 
soning and constraint relaxation, are promising 
ways to overcome these problems. 

A case study from an industrial CIM environ- 
ment, namely high-grade steel production, is 
presented to demonstrate how knowledge-based 
scheduling with the desired capabilities could 
work. By using fuzzy set theory, the applied 
knowledge representation technique covers the 
uncertainty inherent in the problem domain. 
Based on this knowledge representation, a clas- 
sification of jobs according to their importance 
is defined which is then used for the straight- 
forward generation of a schedule. 

A control strategy which comprises organize 
tional, spatial, temporal, and chemical con- 
straints is introduced. The strategy sup- 
ports the dynamic relaxation of conflicting con- 
straints in order to improve tentative schedules. 

1 Introduction 

The task of scheduling jobs and resources in a factory is 
difficult for mainly three reasons. First, one has to deal 
with the combinatorial complexity due to multiple ways 
of job accomplishment [6]. Second, conflicting objectives 
may hinder the definition of an undisputed optimality 
measure [11]. Finally, there is uncertainty in the exe- 
cution of jobs due to the lack of knowledge about the 
exact physical facts underlying the production process. 
Thus, it becomes senseless to compute exact scheduling 
solutions. Often reactive scheduling is proposed as a so- 
lution to these problems [10]. To illustrate the situation, 
an existing scheduling task is described in the following. 

In a joint project between the Alcatel- Elin Research 
Center Vienna and the CD-Laboratory for Expert Sys- 
tems, an expert system was developed. It supports the 


technical staff of the Bohler steelmaking plant in gen- 
erating weekly schedules for steel heats [2]. Side condi- 
tions are the same as for the approach proposed in this 
paper, with the difference that no attempt to handle un- 
certainty was made in this first expert system. Bohler is 
one of the most important European producers of high- 
grade steel. The plant produces tool steel, high-speed 
steel, and stainless steel. There are hundreds of different 
kinds of steel, with 42 chemical elements varying in their 
specification. The requirements concerning steel quality 
are very strong. 

One problem in scheduling is that residuals of one heat 
in the electric arc furnace may pollute the next heat. As 
a general rule of thumb, it can be said that 3% of a 
chemical element in a heat remain on the electric arc 
furnace^ wall, and 3% of the difference of this element 
in the first heat and the second heat will be assimilated 
by the second heat. Two heats that have similar shares 
of the element in question pose no problem. However, 
if the second heat has a much si nailer percentage than 
the preceding one, the pollution by the residual from the 
first becomes too large to be compensated by decreasing 
the amount added to the second heat. This either means 
that the quality of the second heat will be badly influ- 
enced, or if the polluting element is expensive, that it 
will be wasted, and money is lost. In the following these 
two constraints are called compatibility rule. The com- 
patibility rule is effective for all 42 chemical elements, 
but usually only 8 main elements are considered, since 
the others generally are not expensive, do not vary sig- 
nificantly, or have no great impact on the steel quality. 
Uncertainty arises because exact values for the chemical 
elements can very often not be mesured. Further con- 
straints for the scheduling process are temporal, distri- 
bution control, spatial, and resource restrictions on and 
among the aggregates. 

2 Uncertainty Management 

One objective of the presented strategy is to schedule as 
many jobs as possible. In order to get the most impor- 
tant jobs scheduled, the evaluation function for an entire 
schedule must contain a factor representing the impor- 
tance of jobs. Hence, an evaluation function is defined to 
assign an importance value to a schedule by adding up 
the importance values for each job in the schedule. These 
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.005 

hi 

A101 



12.0 

17.8 
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.2 
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11am 
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.1 

.6 
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1.15 

94 

.1 
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.005 
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69 

.005 

.005 
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hi 
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BEST 

1.2 

2.1 

.005 

1.6 

90 

.005 

.005 

.25 

he 

M238 


BEST 

1.2 

2.1 

.005 

1.6 

90 

.005 

.005 

.25 

k 7 

K116 



.1 

12 

.0005 

.4 

83 

.005 

.005 

.005 


Table 1: Characteristics of given heats in the example 


latter values are calculated by considering the resource 
requirements, due dates, and various other attributes of 
individual jobs. 

A first schedule is generated straightforward by con- 
sidering most important jobs first. The first schedule 
may not contain all jobs and still violate some con- 
straints. In these cases, jobs in the schedule will be ex- 
changed to find a proper schedule. A hill climbing search 
method is used to control this exchange. To compare so- 
lutions, an evaluation function based on the given con- 
straints is needed. Fuzzy logic is a sound Al-technique 
to manage uncertainty as present in this problem [8, 12]. 
Since [9], and as recently as in [1], fuzzy logic has been 
successfully applied to knowledge-based scheduling. Our 
approach generalizes these former ones to include, beside 
temporal constraints, other kinds like chemical or orga- 
nizational constraints. 

In section 2.1, we propose a method how the given 
constraints may be represented by fuzzy sets and how 
an evaluation for a complete schedule is computed. Sec- 
tion 2.2 explains the generation of a preliminary schedule 
and the search for a better schedule. Such a schedule can 
only be found if constraints are relaxed, because many 
constraints are antagonistic. This relaxation will again 
be based on fuzzy sets. 

A small example of the application is described to il- 
lustrate the used techniques. The example is restricted 
to one furnace and the planning horizon is only several 
hours. Additionally, only a subset of the given con- 
straints is considered in order to reduce the complexity 
of the example. The existance of a schedule until Sam 
is assumed. The input is a list of jobs that should be 
scheduled. The first heat ho in the list is the latest job 
scheduled from the last scheduling process. The main 
ingredients of each order are given in table 1. 

Three heats of table 1 have special characteristics that 
imply their classification as very important jobs. Heat 
Ji 3 is processed on the continuous caster (CC) and has 
a delivery date. The delivery date is 4pm, the overall 
treatment takes about five hours, and therefore the pro- 
cessing should start at 11am. Heats h$ and he shall 
be cast into big ingots with a special BEST^treatment. 
This implies that they cannot be produced immediately 
one after the other. Instead, there should be a time in- 
terval of at least ten hours between them. 


1 BEST stands for Bohler Electro Slag Topping. 


2.1 Qualitative Representation and Evaluation 
of Constraints with Fuzzy Logic 

The constraints of the given application can be divided 
into three categories: Constraints on a particular job, 
temporal constraints, and constraints on the compati- 
bility of jobs. 

Constraints on a particular job are constraints based 
on required resources or aggregates. They are used to de- 
scribe the importance of jobs. This importance of jobs 
is used later to control the generation of a preliminary 
schedule by scheduling the most important job first. In 
our sense, this importance is a combination of the diffi- 
culty to schedule a job in general and its urgency, that is 
to schedule it for the actual planning horizon. A job that 
requires a bottle-neck resource like the continuous caster 
is usually difficult to schedule. A job with a certain de- 
livery date is important, because it must be scheduled 
in the planning horizon in which the delivery date falls 
Jobs that are not important may be shifted to the next 
planning horizon. To schedule a shifted job eventually, 
it is necessary that the importance of the job increases 
over time. The range of fuzzy linguistic variables to rep- 
resent importance is: urgent , very important, important, 
medium , and not important. 

The classification of jobs in the list is dependent on the 
situation in the actual planning horizon. For instance, 
if for the actual planning horizon many jobs with a high 
chromium- nickel-alloy exist, then a high percentage of 
nickel (Ni) is no problem. On the other hand, when there 
are only few jobs with high nickel percentages, these jobs 
can be difficult to schedule. 

Temporal fuzzy values can be used to describe that 
jobs are too early or too late. The fuzzy value describes a 
degree of uncertainty in both direction. One can identify 
the following linguistic variables: very early , early, in 
time, late , very late. For the evaluation of a schedule 
it makes no difference whether jobs are too early or too 
late. Therefore, the five variables are mapped onto three: 
in time, nearly in time , and not in time. Representation 
of temporal constraints with fuzzy sets is discussed in 
detail in [1, 3, 4, 9]. 

The compatibility of two jobs integrates several fac- 
tors: Different chemical elements, and the work load of 
workers. The compatibility between two jobs is calcu- 
lated by first evaluating the compatibility for each fac- 
tor separately, in order to get restricted compatibility 
measures. Accordingly, we define six fuzzy sets for the 
global as well as for each restricted compatibility: very 
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(D fuzzy number rznge [0,1] **1**1 * 1200 *M*»] 

© region of physical incompatibility. 

<3) H 0 [E] (percentage of element E in Ho), in % of Hi[E]. 
Hq is the heat (job) preceding the heat H\. 


Example: The nickel-compatibility for h $ preced- 
ing hj , both as specified in table 1. According to 
this result, the nickel-compatibility for h$ preced- 
ing hj is more low than medium 


Table 2: Fuzzy inference to compute chemical compatibility between two heals 


high , high, medium, low, very low , and no compatibility. 
The latter is a special case, since a sequence being clas- 
sified incompatible can never be scheduled in this order 
because of hard chemical constraints to be observed. 

The compatibility calculation for nickel is shown in 
table 2. The condition parts of the fuzzy inference rules 
used for this calculation contain statements about the 
percentage of some chemical element in the first heat 
compared to the following heat. In the example taken 
from table 1, the heat h 5 must contain h^[Ni] = 1.2% 
of the chemical element nickel, whereas heat h 7 should 
contain only h 7 [jV*] ss 0.1%. The relative percentage of 
hsfJVt] is therefore 1200% of /^[Nt]. The question is, 
considering only nickel, whether the sequence h 5 preced- 
ing h 7 is allowed or not, and if yes, how good this se- 
quence is. To decide this with the given fuzzy inference 
rules, the linguistic variables and numeric values must be 
matched. This is done with a fuzzy membership func- 
tion as defined in table 2, both for the condition and for 
the conclusion part. In the example, the numeric input 
of 1200% relates more or less with the linguistic vari- 
ables more and much more. Following the dotted lines 
to the conclusion membership functions for such rules 
as “IF the percentage of chemical element E in heat Ho 
is more than in heat H% t THEN the E-compatibility of 
Ho preceding H x is medium” or “IF the percentage of 
chemical element E in heat Hq is much more than in 
heat H\y THEN the E-compatibility of Hq preceding 
Hi is low 3 *, membership functions /ou^/q(h 5 , h 7 ) and 
medtumpvt](^ 5 ) h 7 ) appear as a result of the calculation. 
Their combination is a new membership function defin- 
ing the nickel-compatibility of h$ preceding h 7 . In order 
to compare the result with other compatibilities, it must 
be defuzzified. This can be done by calculating the cen- 
ter of gravity of the surface and then taking the value 
of its x-coordin&te as the result, a standard method in 
fuzzy calculation [8]* 

The conditions of the fuzzy inference rules consider 
only relative values for the percentage of elements like 
nickel in the two compared heats. Absolute values are of 


minor interest for the compatibility problem, but could 
easily be modeled by introducing more complex three- 
dimensional membership functions. We chose a half- 
logarithmic graduation to be able to handle those rel- 
ative values. Since the compatibility rule is asymmetric 
and only restricts the second heat to a minimal value 
for a certain chemical element, which must at least be 
present in this heat, the graduation is asymmetric, too, 
and only logarithmic on the right half. Beside simplify- 
ing the visualization, this logarithmic scale has an ad- 
ditional positive effect, since positions on the right side 
of the 100% mark that are still near the center, are pre- 
ferred and get more attention per unit than positions 
more close to the physical limit on the far right This 
reenforces the natural meaning of the fuzzy linguistic 
variables positively. 

The fuzzy inference rules like those used in table 2 
give several fuzzy judgements how compatible the heats 
are. These judgements in form of membership functions 
can be simplified to the linguistic variable to which the 
judgement mainly pertains. The resulting fuzzy-values 
can all be combined by computing a weighted mean of 
the defuzzified values to get one overall value for the two 
heats: 

comp^H,, Hj) = g(E)comp [E] {H l , H } ) 

E£{WI,Ni,Cr, ) 

In this formula, g(E) is the normalized weight of a rule 
and E is a member of the set of all factors influencing the 
compatibility, namely work load (Wl) and the 42 chemi- 
cal elements like nickel or chromium. This computation 
is done for every pair of jobs that may be scheduled. The 
result is a matrix of fuzzy values where the fuzzy values 
describe how compatible the sequence of the job of a 
column after the job in a row is according to all rules. 
After defuzzifying the matrix, numeric values that can 
be rematched with the original fuzzy linguistic variables 
can be written in the matrix. 

Table 3 shows the matrix for the example. It will 
be used for the construction of the preliminary sched- 
ule and during the improvement process To evaluate 
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Note: Ho precedes Hi , e.g., the compatibility of heat h$ preceding k 2 is high, whereas 62 preceding ha is very low. 


Table 3 : Compatibility matrix for heat sequences 


compatibility. high medium low 


Ho 




high very low low 

| /»2 I />! | /»6 


5am 


7am 


9am 


11am 


1pm 


3pm 


5prn 


Table 4 : Preliminary schedule for example heats 


schedules during improvement steps, it is necessary to 
compute an evaluation function for the compatibility of 
the entire schedule. This can be achieved with a fuzzy 
and-operator. 

2.2 Generating a Schedule 

To generate a preliminary schedule, the jobs are classi- 
fied regarding their importance. Then they are sched- 
uled in the sequence of their importances. Scheduling 
a job means assigning a temporal interval to it. These 
intervals are spread over the entire planning horizon be- 
cause of temporal and resource constraints. During the 
scheduling process, empty intervals are created between 
scheduled jobs. The compatibilities with the jobs before 
and behind this empty interval are not considered. If 
empty intervals with a duration of approximately one 
job are created, they are filled with compatible jobs as 
long as there are some available. 

Usually, some jobs can not be scheduled, because no 
interval exists where they would not violate some com- 
patibility constraints. In addition, some empty intervals 
remain in the schedule, and the compatibility between 
the jobs adjacent to this interval is usually bad. In order 
to cope with the given complexity, instead of backtrack- 
ing to the last scheduling decisions, such a preliminary 
schedule is repaired or improved by exchanging jobs. 

In the list of jobs given in table 1 , job h$ has a deliv- 
ery date. It will be scheduled first. Thereafter, jobs 
and /*6 will be scheduled, because they are very difficult 
jobs. They include a special treatment and therefore 
need a long time span between each other. Fortunately, 
one of them fits well after ho. is choosen to be the 
successor of ho* The other is scheduled at the end of the 
planning horizon. The job h 7 is scheduled between h$ 
and /13 to close the empty interval between them. Heat 
h 2 is another difficult job for the actual planning hori- 
zon, because most heats have high percentages of nickel 
(Ni) and chromium (Cr), and h 2 has only small amounts 
of both. Moreover, h 2 has large amounts of vanadium 
(V) and tungsten (W). The best place for h 2 is behind 


heat /13. An empty interval remains between h 2 and h&. 
There exists no heat in the given list that fits between h 2 
and h 6 * To fill the interval, hi is scheduled between h 2 
and ho. Heat h* remains for the next planning horizon. 
This preliminary schedule is illustrated in table 4 . 

To improve a schedule, a measure for schedules that 
evaluates which schedule of two is the better one is 
needed. Unfortunately, the violation of constraints can 
have far-reaching consequences. The violation of a tem- 
poral constraint can cause the need for more resources 
such as additional energy, or rescheduling in subsequent 
plants. The violation of chemical compatibility can re- 
sult in the loss of a heat which would be a heavy fi- 
nancial damage. On one hand, one must consider hard 
constraints that may not be relaxed, and on the other 
hand constraints must be relaxed to a certain degree in 
order to get a feasible schedule with as many jobs as 
possible. In order to evaluate all these antagonistic con- 
straints, an evaluation function based on the introduced 
fuzzy values is needed. 

The actual schedule is called the “currently best sched- 
ule”. To improve a given schedule, a potential constraint 
violation that could be improved is searched. In the ex- 
ample, such a violation is found between heat h-> and h] 
Therefore one of them is taken out of the schedule. If 
hi is taken, no other heat is found in the whole list that 
would fit better. Therefore h 2 is taken out of the sched- 
ule and another heat that fits better is searched. h 2 can 
be replaced by A4 and one gets the schedule shown in ta- 
ble 5 which is the “current best schedule”, because the 
evaluation function based on fuzzy sets assigns a better 
value to this schedule than to the old one. 

In the next step, the compatibility of h 7 preceding h 3 
is found low. Therefore a job that would be a better 
predecessor of /13 is searched. Heat /15 is the best fit 
There are two possibilities: a heat that can be processed 
between ho and h$ can be searched, or h 3 can be simply 
shifted in time. Regarding only the compatibility con- 
straints, the best solution would be to exchange and 
/17. Unfortunately, another constraint is violated in this 
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Table 6 : Final schedule for example heats 


case: The interval between the heats A 5 and A 6 should 
be at least 10 hours. Therefore heat A 3 will be shifted. 
Since delivery dates may be shifted up to two hours, heat 
/»3 can start at 9am and heat Ay started after A 3 . The 
result is the schedule shown in table 6 . 

Every exchange of jobs in the schedule can be inter- 
preted as one operator in a search process. The search 
for better schedules can be guided by heuristics based on 
our evaluation function. This heuristic search is a kind 
of hill climbing method. Unfortunately, the disadvan- 
tage of a hill climbing method is that it can be caught 
in local maxima. In [7] a technique called TABU search 
is described that can be used to overcome this problem. 

The search will end if no more constraint violations 
can be detected, or no further improvement can be 
achieved. It is not that easy to say that no further 
improvement can be achieved. Here it makes sense to 
define a distance function between an optimal schedule 
where all compatibilities would be very high, and all the 
other constraints would be observed too. If there is such 
a distance function, the search effort can be restricted 
by a ratio between distance and search effort. It would 
be fruitless to invest much more search effort if only a 
small distance exists. On the other hand, if the distance 
is large, one should search longer for a better schedule, 

3 Conclusion 

Due to highly unreliable knowledge and conflicting 
objectives in scheduling applications, mathematical- 
analytical methods as used in Operation Research ap- 
proaches are insufficient in many cases. We have illus- 
trated this very problem for a steelmaking plant. In 
order to overcome this deficiency we have developed a 
solution which combines two sound Al-techniques for 
problem solving: Approximate reasoning and constraint 
relaxation. 

We believe that, using the described techniques, the 
development cycle for scheduling expert system becomes 
shorter, the knowledge representation easier, and bet- 
ter schedules can be generated compared to earlier used 
techniques. 
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Abstract 

This paper describes DTS, a decision- 
theoretic scheduler designed to employ state- 
of-the-art probabilistic inference technology 
to speed the search for efficient solutions 
to constraint-satisfaction problems. Our ap- 
proach involves assessing the performance of 
heuristic control strategies that are normally 
hard-coded into scheduling systems, and us- 
ing probabilistic inference to aggregate this 
information in light of features of a given 
problem. 

BPS, the Bayesian Problem-Solver [2], intro- 
duced a similar approach to solving single- 
agent and adversarial graph search prob- 
lems, yielding orders-of-magnitude improve- 
ment over traditional techniques. Initial 
efforts suggest that similar improvements 
will be realizable when applied to typical 
constraint-satisfaction scheduling problems. 

1 Background 

Scheduling problems arise in schools, in factories, in 
military operations and in scientific laboratories. Al- 
though many algorithms have been proposed, schedul- 
ing remains among the most difficult of optimization 
problems. Because of the problem’s ubiquity and com- 
plexity, small improvements to the state-of-the-art in 
scheduling are greeted with enormous interest by prac- 
titioners and theoreticians alike. 

A large class of scheduling problems can be repre- 
sented as constraint-satisfaction problems (CSPs), by 
representing attributes of tasks and resources as vari- 
ables. Task attributes include the scheduled time for 
the task (start and end time) and its resource require- 
ments. A schedule is constructed by assigning times 
and resources to tasks, while obeying the constraints 

•This research was supported by the National Aeronau- 
tics and Space Administration under contract NAS 2-1 3340. 


of the problem. Constraints capture logical require- 
ments (a typical resource can be used by only one task 
at a time) and problem requirements (task T x requires 
N units of time, must be completed before task T y , 
and must be completed before a specified date). 

One common approach to finding an assignment 
for the variables employs a preprocessing stage which 
tightens the constraints (e.g., by composing two con- 
straints to form a third), followed by a backtrack search 
to find a satisfying assignment. Figure 1 illustrates the 
operation of such a search algorithm: searching depth- 
first until a dead-end is reached, and then backtracking 
to the nearest choice point to continue the search. 



no legal values 
(dead-end) 


Figure 1: Basic CSP Algorithm 

Heuristic functions guide the ordering of variables 
and values. For example, one heuristic for variable or- 
dering counts the number of possible values for each 
variable, and chooses the variable with the smallest 
number of values as the next to instantiate. Typi- 


cally, the variable ordering in backtracking algorithms 
is static, determined prior to search by use of a heuris- 
tic function. As heuristics for variable and value or- 
dering form the basis for the algorithm’s performance, 
tremendous effort has been invested in developing good 
general-purpose heuristics. However, practitioners of- 
ten bypass the general-purpose heuristics in favor of 
hand-crafted domain-specific heuristics (e.g.. Sadeh’s 
work [8]). 

2 DTS Rationale 

CSP heuristics are imperfect and exhibit highly 
domain-specific performance. Although they often pro- 
vide useful search control advice, the possibility of er- 
ror introduces uncertainty into the search algorithms 
which rely on them. Consequently, current techniques 
are forced to pay a large computational price in cases 
where the heuristic function makes incorrect classifica- 
tions. Furthermore, the algorithms will repeat these 
costly mistakes, as there are no robust learning mech- 
anisms designed to improve a CSP heuristic’s perfor- 
mance over time. 

Existing heuristic functions encode many different 
domain attributes. Some estimate the quality of partial 
schedules while others estimate the difficulty of finding 
a feasible solution. Unfortunately, there is no sound 
methodology for combining the information provided 
by an arbitrary number of heuristics for use in control- 
ling a single search. This forces human schedulers to 
make an unpleasant choice: 

• decide a priori on a particular heuristic, and thus 
concentrate on a single domain attribute. This 
can skew the system’s performance at the expense 
of other domain attributes, 

• hand-craft a composite heuristic which captures 
multiple domain attributes in a single function. 

For this reason, the selection of heuristics and problem- 
solving techniques for any given CSP domain remains 
an art despite years of comparative study. 

DTS, which is derived from previous work on BPS 
(the Bayesian Problem- Solver), is designed to address 
these problems. The first area of innovation is the 
heuristic error model : a probabilistic semantics for 
heuristic information, based on the concept of con- 
ditional probability in statistical decision-theory [3]. 
Heuristics are interpreted by correlating their estimates 
with the actual payoffs of problem-solving instances. 
When a problem is solved, the heuristic error model 
is updated, adapting it to the problem’s specific char- 
acteristics. Multiple heuristics are combined by corre- 
lating payoffs with a set of heuristic estimates. This 
alleviates the human scheduler’s dilemma by provid- 
ing a dominating alternative, a sound framework for 
combining an arbitrary number of heuristic functions. 

The second area of innovation is the use of multi - 
attribute utility theory, a formalized method for quan- 


tifying preference relationships among a set of uncer- 
tain outcomes. An important target application for 
DTS is experiment scheduling for the Hubble Space 
Telescope. Figure 2 depicts a partial set of utility at- 
tributes, whose non-linear tradeoffs can be encoded 
by a multiattribute utility function. In contrast to 


Schedule Utility 



Figure 2: Utility Attributes for Experiment Scheduling 

traditional CSP scheduling algorithms, which employ 
special-purpose control rules, DTS’s control rule is the 
decision-theoretic rationality criterion of maximizing 
expected utility. - - - - 

In DTS, domain information is encoded in heuris- 
tic functions and user preferences are encoded in util- 
ity functions. By combining domain-independent and 
domain-specific heuristics, and then using the user’s 
utility function to make search control decisions, DTS 
provides a more efficient and flexible alternative to tra- 
ditional scheduling techniques. 

3 DTS: First Results 

This section describes empirical results illustrating the 
performance advantages of these two DTS innovations. 

3.1 Combining Heuristics 

The primary strength of the DTS prototype is the 
method for combining information from separate 
heuristic evaluation functions to improve constraint- 
satisfaction search control. Experiments with the pro- 
totype on the Eight Queens and Bridge-Construction 
Scheduling [9] problems confirm that the combination 
of heuristic functions provides more information than 
any of the heuristics taken individually. This translates 
into significant reductions in overall search time. 

Traditionally, CSP algorithms make use of a vari- 
able ordering heuristic and a value ordering heuristic. 
Figure 3 shows the performance of a standard CSP 
algorithm using all possible pairs (Al, A2, Bl, B2) 
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Figure 3: Eight Queens: Combining Heuristics vs. 
Heuristics in Isolation 


drawn from two well-known variable ordering heuris- 
tics (Most Constraining Variable (A), Minimum Do- 
main Variable (B)) and two well-known value order- 
ing heuristics (Least Constraining Value (1), Dechter’s 
Value Heuristic (2)[1]). Also shown is the DTS pro- 
totype (DTS- Joint), which dominated the competition 
by using all four heuristics in combination. The hor- 
izontal axis plots the number of problem instances 
solved and the vertical axis plots the running average 
of search time over the entire experiment. The plot, 
but not the average, beging with the tenth problem 
instance. 

Figure 4 shows a corresponding graph for the Bridge- 
Construction Scheduling problem. The variable order- 
ing heuristic used was Minimum Domain Variable and 
the value ordering heuristics were Least Constraining 
Value (curve Al) and ASAP, “as soon as possible” 
(curve A2). Also shown are the corresponding indi- 
vidual DTS performance curves (DTS Al, DTS A2) 
as well as the combined heuristic performance curve 
(DTS- Joint). 

To summarize both graphs, the improvement is seen 
to be nearly 50% on average for Bridge Construc- 
tion Scheduling, and over 95% for the Eight-Queens 
problem. Note that the sharp downward slope of 
the DTS- Joint running average in Figure 4 demon- 
strates the performance improvement accrued by learn- 
ing, unattainable using traditional techniques. 

3.2 Learning Heuristic Error Models 

Figure 5 displays an example heuristic error model 
learned over the course of 2500 Eight-Queens problem 
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Figure 4: Bridge-Construction Scheduling: Combining 
Heuristics vs. Heuristics in Isolation 


instances (for the Minimum Domain heuristic). The 
horizontal axis plots the heuristic function estimate 
and the vertical axis plots the preference for that esti- 
mate. In DTS, preference is based upon the expected 
utility associated with a heuristic estimate (dashed 
line). In traditional algorithms, the heuristic is as- 
sumed to rank-order alternatives perfectly, and there- 
fore, preference is a monotonic function of the heuristic 
estimate. 
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Figure 5: Sample Heuristic Error Model 

The discrepancy between the heuristic estimates and 
the actual utilities explains the poor performance of 
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traditional approaches, which assume perfect heuristic 
estimates. Further, it explains why DTS outperforms 
these techniques, as it does not make this assumption, 
and instead learns to correct for the discrepancy. 
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Figure 6: Generalizing Data to Larger Domains 

An additional benefit of the heuristic error model is 
the ability to generalize learned data across domains. 
For example, Figure 6 depicts the performance of DTS 
on the Thirty-two-Queens problem with 1) no prior 
heuristic error model, and 2) a heuristic error model 
generalized (or “bootstrapped”) from the 2500 Eight- 
Queens examples solved in Figure 3. Generalizing data 
from the simpler domain has reduced search complex- 
ly* This is particularly important as the time required 
to calibrate heuristic error models increases with prob- 
lem complexity. 

3.3 Decision-Theoretic Backtracking 

The DTS prototype employed a simplified decision- 
theoretic control mechanism which was adapted to a 
conventional backtracking search algorithm; this al- 
lowed for controlled experiments on DTS vs. tradi- 
tional algorithms. The application of decision theory 
to backtracking elucidates many important ideas. 

The only search control decisions made in traditional 
backtracking systems are the selections of which sub- 
trees of the search graph to explore next. Once a sub- 
tree is selected (by selecting the next variable or value), 
it is explored exhaustively unless a solution is found. 
Such an ordering problem can be viewed as a decision- 
tree. Figure 7 depicts the choice of ordering two sub- 
trees A and B. We have proven a theorem [4] which 
shows that the system's expected utility (search time 
to first solution) is maximized if variables (or values) 
are ordered by the quantity P(v)/C(v), where P(v) in- 
dicates probability of finding a solution in the subtree, 


and C(v) indicates the cost of searching the subtree 
(whether or not a solution is found). P(v) and C(v) 
are attributes of the payoff mentioned above. Experi- 
ments confirmed that once P(v) and C(v) are learned, 
this rule outperforms traditional backtracking search 
algorithms which interpret heuristic estimates at face 
value. This result indicates that decision-theoretic 
search-control improves overall system performance. A 
similar analysis can also be performed for iterative im- 
provement [4], 



Figure 7: Decision Tree for Value-Ordering Problem 
(Values A and B) 


As is evident from this discussion, DTS must con- 
vert raw heuristic estimates at a node into estimates 
of (1) probability of finding a solution in the subtree 
under that node, and (2) the cost of search in that 
subtree. We note here that while heuristics are usually 
very good at rank-ordering nodes based on (1) and (2) 
individually, the rank-ordering for the combination is 
typically incorrect. DTS' heuristic error model corrects 
for this. 


3,4 Implementation Synopsis 

The prototype performs a backtracking search, using 
the standard optimizations of forward-checking and dy- 
namic search rearrangement. The search is ordered by 
the expected utility selection criteria ( P(v)/C(v )) dis- 
cussed above. The estimates of P(v) and C(v) are de- 
rived from the heuristic error model, using traditional 
CSP heuristics. The heuristic error model is updated 
during and between trials using a bucketed histogram, 
and interpreted by a Laplacian estimation. 
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4 Future Directions 

Our initial study of CSP and scheduling domains 
demonstrates that applying even the simplest modeling 
techniques of statistical decision theory can yield sig- 
nificant payoffs. There are many other aspects of CSP 
algorithms which would benefit from a similar decision- 
theoretic approach. We conclude with two such exam- 
ples. 

4.1 Preprocessing and Caching of 
Learned Constraints 

Our decision-theoretic approach could be applied 
equally well to the control of scheduling subprob- 
lems. For example, Minton [5] has considered a simple 
utility-based model of the selective caching of learned 
problem-solving rules. 

Minton demonstrated that the caching of too many 
rules acquired from problem-solving instances leads 
to a substitution of knowledge-search (searching the 
rule cache for an applicable rule) for problem-solving 
search. Similarly, in a CSP problem, any number of 
implicit constraints can be generated by preprocessing 
or constraint-recording and cached in the constraint 
graph. But additional constraints, while reducing 
problem-solving search, increase the number of consis- 
tency checks per search tree node (knowledge search). 
Choosing to generate and record a constraint is, again, 
a decision made under uncertainty, and it would be in- 
teresting to consider a decision-theoretic approach to 
the problem. We feel that decision-theoretic modeling 
and the simple structure of CSPs can provide a firmer 
theoretical foundation for this area of research. 

4.2 Selective Value Generation 

A common problem among search algorithms is selec- 
tive expansion of successors. The textbook description 
of most search algorithms calls for a full expansion of all 
successors of a given node. For constraint-satisfaction 
problems, this is clearly inadequate, as many variables 
such as task start and end times have an infinite num- 
ber of infinitesimally-spaced values. 

One possible approach employs heuristics for value 
generation. While we have applied decision theory to 
search by designing an algorithm which evaluates all 
successors and then selects among them, it is equally 
possible to apply these tools to selective expansion of 
successors. If several heuristics (dispatch rules) can be 
used to suggest plausible values, our approach can be 
applied to the heuristics trivially. If no such heuris- 
tics exist, one possibility is to employ a tree of values, 
and perform an auxiliary search of this tree to select a 
particular value. This brings on a new learning task: 
clustering values of similar merit into a hierarchy of 
values. 


5 Conclusion 

The use of Bayesian probability theory in DTS un- 
derscores that scheduling involves decision-making un- 
der uncertainty, and illustrates how imperfect infor- 
mation can be modeled and exploited. The use of 
multiattribute utility theory in DTS underscores that 
scheduling involves complex tradeoffs among user pref- 
erences. By addressing these issues, DTS has demon- 
strated promising performance in preliminary empiri- 
cal testing. 
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Abstract 

A project scheduling problem consists of a finite set of jobs, 
each with fixed integer duration, requiring one or more resources 
such as personnel or equipment, and each subject to a set of 
precedence relations, which specify allowable job orderings, and 
a set of mutual exclusion relations, which specify jobs that cannot 
overlap. No job can be interrupted once started. The objective 
is to minimize project duration. This objective arises in nearly 
every large construction project — from software to hardware to 
buildings. Because such project scheduling problems are NP- 
hard, they are typically solved by branch-and-bound algorithms. 
In these algorithms lower-bound duration estimates (admissible 
heuristics) are used to improve efficiency. One way to obtain 
an admissible heuristic is to remove (abstract) all resource and 
mutual exclusion constraints and then obtain the minimal project 
duration for the abstracted problem; this minimal duration is 
the admissible heuristic. Although such abstracted problems can 
be solved efficiently, they yield inaccurate admissible heuristics 
precisely because those constraints that are central to solving the 
original problem are abstracted. This paper describes a method 
to reconstitute the abstracted constraints back into the solution 
to the abstracted problem while maintaining efficiency, thereby 
generating better admissible heuristics. Our results suggest that 
reconstitution can make good admissible heuristics even better. 

1 Introduction 

One way to solve a difficult problem is to simplify it by 
removing certain details, solve the simplified problem, and 
then use its solution as a guide for solving the original 
problem. For example, in solving a difficult physics prob- 
lem, details such as friction might be ignored. Although 
the simplified problem might be easy to solve, it might ig- 
nore precisely those details that are central to solving the 
original problem. This paper describes a method called re- 
constitution that adds back such ignored details to the sim- 
plified problem’s solution, thereby providing a better guide 
for solving the original problem. The ultimate goal of this 
research is to develop an automatic reconstitution system, 
thereby shifting some of the simplification and problem- 
solving from humans to machines. 

As a vehicle for exploring reconstitution, we are currently 
focusing on project scheduling problems because they are 
of practical importance and are difficult to solve. A project 
scheduling problem consists of a finite set of jobs, each 
with fixed integer duration, requiring one or more resources 
such as personnel or equipment, and each subject to a 
set of precedence relations, which specify allowable job 
orderings, and a set of mutual exclusion constraints, which 
specify jobs that cannot overlap. No job can be interrupted 
once started. The objective is to minimize project duration. 
Since this objective arises in nearly every large construction 


project — from software to hardware to buildings — efficient 
algorithms that obtain that objective are desirable. 

Integer linear programming methods have been used to 
solve project scheduling problems for years [1, 2, 13, 7], 
However, these methods are computationally expensive, un- 
reliable, and applicable only to problems of small size. The 
underlying reason for the computational expense and lim- 
ited problem size is that such project scheduling problems 
are NP-hard (see the Appendix). As a result, such prob- 
lems are typically solved by branch-and-bound algorithms 
with lower-bound duration estimates (admissible heuristics) 
to improve efficiency [21, 4], In addition to improving ef- 
ficiency, admissible heuristics have other several other de- 
sirable properties in various branch-and-bound algorithms 
such as guaranteeing minimal project duration [16] or guar- 
anteeing a project duration no longer than a certain factor 
of the minimal one [18]. 

Several researchers have shown how admissible heuris- 
tics can be derived by simplifying the original problem 
via abstraction (ignoring certain details) and then using the 
length of a shortest path solution in the abstracted prob- 
lem as the admissible heuristic [8, 6, 17, 11, 15, 19, 20]. 
For example, the Manhattan Distance heuristic for sliding 
block puzzles is derivable by ignoring the blank. For such 
heuristics to be effective, the abstracted problem that gener- 
ates them should be efficiently solvable and yet close to the 
original problem [22, 15, 22], Typically, the more details 
that are removed, the easier the problem is to solve and the 
less accurate the resulting heuristics. This tension between 
accuracy and ease of solvability makes discovering those 
abstracted problems that are easy to solve and close to the 
original problem a difficult task [19]. 

The only published attempt at discovering admissible 
heuristics with this approach in a scheduling domain yielded 
poor heuristics [14, 20]. Moreover, the particular schedul- 
ing problem (uniprocessor scheduling) to which it was ap- 
plied did not allow concurrency, which is the essence of 
scheduling. One of the contributions of this paper is to 
apply abstraction-based heuristic derivation techniques to 
a scheduling problem where concurrency is allowed (i.e. 
project scheduling). 

The other contribution of this paper is an automatic 
method to reconstitute an abstract solution, thereby boosting 
the effectiveness of an admissible heuristic. The idea that 
abstraction-derived heuristics can sometimes be made more 
effective by taking into account certain details ignored by 
the abstracted problem was first expressed by Hansson, 
Mayer, and Yung [9]. In particular, they hand-derived 
a new effective admissible sliding block puzzle heuristic 
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(the LC heuristic) by taking into account those linear tile 
conflicts (same row or column) ignored by the Manhattan 
Distance heuristic. We have extended this idea to a problem 
involving time rather than solution path length: scheduling. 

2 Definition of Key Terms 

As shown in Figure 1, a scheduling problem can be repre- 
sented as graph with jobs as vertices, precedences as single- 
arrowed edges, and mutual exclusions as double-arrowed 
edges. For example, the figure shows that job I must be 
completed before job J can start and that jobs J and K 
cannot overlap. The single number above each job repre- 
sents the job’s duration. For example, job J takes 10 units 
of time to complete. The letter to the left of each job rep- 
resents the resource that the job requires; one job’s use of a 
resource cannot overlap with another job’s use of that same 
resource. For example, jobs I and E, which both require 
resource s, cannot overlap with each other. 

A precedence graph is a directed acyclic graph consisting 
only of the precedence relations and no resource constraints. 
An early schedule graph is derived from the precedence 
graph, where each job is scheduled as early as possible. 
The numbers within the square brackets near each job in 
the figure represent the earliest start time and the earliest 
completion time of each job. The critical path is the longest 
path in the early schedule graph; it shows the earliest time 
by which all jobs can be completed. 

No job on the critical path can be delayed, although other 
jobs on the same early schedule can be delayed as long as 
they do not increase die critical path length. For example, 
if job J, which is on the critical path, starts later than 33 
units of time, the entire project will be delayed. These jobs 
may have to be delayed in order to satisfy mutual exclusion 
constraints. The total completion time of an early schedule 
is therefore equal to the critical path length, which in our 
case is 43. An optimal schedule is an early schedule which 
takes the least total time among all possible schedules. Note 
that jobs within an optimal schedule may not be scheduled 
optimally, according to this definition. 

Given only precedence constraints, finding an early 
schedule reduces to a topological sort of the precedence 
graph, which can be done in linear time of the number of 
jobs [10]. Finding the critical path in an early schedule also 


takes linear time of the number of jobs. Therefore, if all 
other constraints such as mutual exclusion constraints and 
resource constraints can be recast as precedence constraints, 
the problem is easily solvable. For example, the mutual ex- 
clusion constraint between jobs J and K can be recast in 
two ways: either J is completed before K or vice versa. 
Similarly, for resource constraints each pair of jobs shar- 
ing the same resource can be recast as a mutual exclusion 
constraint between the two jobs. Each mutual exclusion 
constraint can then be recast as one of two precedence con- 
straints as previously described. 

3 Branch and Bound Project Scheduling 

The idea of recasting mutual exclusion and resource con- 
straints as precedence constraints suggests the following 
simple combinatorial algorithm. Explore all recastings, one 
at a time, that do not create a cycle and find early sched- 
ules for all of these recastings; the early schedule with the 
minimum critical path length is the optimal one. Unfortu- 
nately, this brute-force algorithm is combinatorially explo- 
sive: n mutual exclusion constraints results in 2" possible 
recastings, which is clearly too large a space to explore 
exhaustively for large n. One way to reduce this combina- 
torial explosion is to use a branch-and-bound algorithm with 
lower-bound estimates to prune certain recastihgs earlier. If 
the current duration + the lower-bound estimate exceeds a 
given upper-bound, then that schedule can be pruned. 

The critical path estimate of ah early schedule, which is 
efficiently computable, is clearly a lower-bound since any 
early schedule that satisfies part of the constraints is a lower 
bound on the completion time for any optimal schedule sat- 
isfying all constraints. Moreover, any additional constraint 
will not result in a decrease in the critical path length. No- 
tice that the critical path (CP) heuristic results from an ab- 
straction of the original problem: all mutual exclusion and 
resource constraints are ignored. 

Although the CP heuristic is admissible and easily com- 
putable and has proved to be valuable in evaluating overall 
project performance and identifying bottlenecks, it can be 
far from the actual project duration. In the worst case, it 
can underestimate the actual project duration by a factor 
of n, where n is die total number of jobs to be scheduled. 
This case arises when the only possible schedule is a se- 
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8. If no such constraint is found, return the CP length as the new bound. . 


Figure 2 An Algorithm to Compute the RCP Heuristic 


rial schedule. For example, if a scheduling problem has no 
precedence constraints and has mutual exclusion constraints 
between every pair of jobs, then the only possible schedule 
will be a serial one. For this case, the CP heuristic will 
return length of the longest job, which underestimates the 
optimal duration by a factor of n. Also, since the critical 
path estimate ignores the resource constraints, certain se- 
quencing decisions may be required in the actual schedule 
that increase the project duration well beyond the critical 
path estimate. 

4 Reconstitution-based Heuristics 

What we would like is an admissible heuristic that is as 
easily computable as the critical path estimate, but that takes 
into account the resource and mutual exclusion constraints, 
which the critical path estimate ignores. We would like to 
reconstitute these ignored constraints back into the critical 
path somehow. The RCP (Reconstituted Critical Path) 
heuristic described below does exactly that. 

The basic idea behind the RCP heuristic is to extend the 
critical path by analyzing all unsatisfied mutual exclusion 
constraints between jobs in critical path and jobs not in 
critical path. When possible, all jobs with such unsatis- 
fied constraints are rescheduled at a later time while still 
preserving critical path length. If that is not possible, then 
the critical path length is increased by a time overlap un- 
derestimate between the jobs of each type. For example, 
consider the project scheduling problem in Figure 1, which 
has a critical path of J, F, C, B, A. First, we examine job 
J and check for any mutual exclusion constraints involving 
it The only such constraint is the one with job K. Next, 
we check if J overlaps with K, which in fact it does. The 
object now is to try to delay job K beyond the completion 
time of job J, which is at 43 time units. Delaying job K 
will necessarily increase the length of the critical path by 
1 time unit. If the rest of the jobs were ignored, the RCP 
heuristic would return 44, which is the length of critical 
path (43) plus the overlap of the earliest start time of job J 
and the earliest completion time of K (34 - 33 = 1). The 
general algorithm is shown in Figure 2. (We assume that 
resource constraints have been recast as mutual exclusion 
constraints.) 


To see that the RCP heuristic is admissible, consider a 
job ji on the critical path which has a mutual exclusion 
constraint with job j m . In the final schedule, either j t will 
be scheduled before j m or vice versa. Note that neither of 
the two jobs can be scheduled any earlier since the schedule 
is already an early schedule. If job j m cannot be scheduled 
after j t without increasing the critical path length in the 
current schedule by pushing jobs ahead which depend on 
j m , then neither can it be scheduled after j t in the final 
schedule. The reason is that precedence constraints are 
always added and never removed at each iteration of the 
search algorithm and adding more precedence constraints 
cannot invert an existing scheduling order. If ji is scheduled 
after j m , then the critical path length will be increased by at 
least the minimum of the overlap between the earliest start 
time of ji and the earliest completion time of j m or the 
earliest start time of j m and the earliest completion time 
of j,. 

Although the RCP heuristic takes slightly longer to com- 
pute than the CP heuristic, it prunes more of the space than 
the CP heuristic. As we will see in the next section, the 
extra time taken in computing the heuristic is more than 
compensated by the time saved from pruning the search 
space. If the current critical path length is optimal, then 
computation of the RCP heuristic takes longer than that of 
the CP heuristic, since the algorithm has to examine all jobs 
on the critical path. The worst case complexity of comput- 
ing the RCP heuristic is 0(n 2 ) for n jobs, since at most 
O(n) jobs will be on the critical path and 0(n ) work will 
be required to process a mutual exclusion constraint involv- 
ing a job on the critical path. An analysis of the average 
computational complexity is, however, difficult since the 
heuristic depends on specific mutual exclusion constraints. 
The degree of complexity can be controlled by reconstitut- 
ing less mutual exclusion constraints, if desired. 

The complexity of the RCP heuristic can be further re- 
duced by computing it incrementally. Since new prece- 
dence constraints are added and never removed at each it- 
eration of the search algorithm, the critical path up to the 
point in the graph where the new precedence constraint is 
added remains the same and the critical path need only be 
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CP Heuristic 


RCP Heuristic 


Jobs 

Precedences 

Mutual 

Exclusions 

StaUs 

Expanded 

CPU Seconds 

Bytes 

States 

Expanded 

CPU Seconds 

Bytes 



0 

0 

.25 

30820 

0 

.25 

30808 



10 

14 

5.43 

41024 

14 

8.52 

58108 

30 

112 

15 

19 

5.98 

43212 

19 

9.18 

70256 



20 

6237 

1644.17 

45796 

49 

30.58 

109584 



25 

6242 

1651.53 

47188 

54 

30.67 

116068 



10 

12 

5.15 

52928 

12 

5.63 

72228 


1 Off 

20 

24 

9.73 

56988 

24 

18.52 

101936 

40 

125 

30 

1084 

718.20 

71024 

431 

494.33 

194220 



40 

1096 

727.83 

65104 

521 

521.80 

224112 


Table 1 Comparative Performance Analysis of the CP and RCP Heuristics with IDA’ 


recomputed from that point on. 

5 Empirical Results 

To get some idea of the effectiveness of the RCP and 
CP heuristics, we implemented the IDA* algorithm [12], 
which is a standard branch-and-bound algorithm in which 
to evaluate admissible heuristics, in Quintus Prolog on a 
Sun Sparstation 1+ and ran it on a set of random solvable 
(i.e. no cycles) problem instances with various numbers 
of Jobs, mutual exclusion constraints, and precedence con- 
straints. The algorithm works as follows. All partial sched- 
ules whose duration exceeds a certain threshold are pruned. 
Initially, the threshold is set to the value of the admissible 
heuristic on the initial state. If no solution is found within 
that threshold, then the algorithm repeats with a new thresh- 
old set to the minimum of duration plus heuristic estimate 
over all the previously generated partial schedules whose 
duration exceeds the threshold. One important property of 
IDA* is that it guarantees minimal duration solutions with 
admissible heuristics. 

A state consists of three items: 

1. A precedence graph which includes original prece- 
dence constraints and a set of precedence constraints 
originating from mutual exclusion constraints which 
have so far been recast as one of two precedence con- 
straints. 

2. Anearly schedule satisfying the precedence constraints. 

3. A set of unsatisfied mutual exclusion constraints. 

The goal state is characterized by an empty mutual ex- 
clusion constraint set. A state transition is a recasting of a 
mutual exclusion constraint into one of two precedence con- 
straints followed by the generation of a new early schedule. 
Search proceeds from an initial schedule satisfying only 
the original precedence constraints. (Our implementation 
assumes that resource constraints have been recast as a set 
of mutual exclusion constraints.) 

We ran two sets of experiments, each with a fixed the 
number of jobs and precedence constraints and a variable 


number of mutual exclusion constraints since problem com- 
plexity grows as the number of mutual exclusion constraints 
increases: one with 30 jobs with 112 precedence constraints 
and the other with 40 jobs with 128 precedence constraints. 
For the first set, we varied the number of mutual exclusion 
constraints between 0 and 25; for the second, between 10 
and 40. We chose these problems because they were the 
largest ones we could generate that still could be solved in 
a reasonable amount of time on our machine. 

Table l summarizes the results of running IDA* on these 
two problem sets. For each problem set, the table lists 
the number of mutual exclusion constraints, the number of 
states expanded, the CPU time, and the amount of run- 
time memory used. As the table shows, for problems 
with few mutual exclusion constraints, the number of states 
expanded in both cases remain the same and CP consistently 
takes less time than RCP, since RCP does more work each 
time. However, for all problems where RCP resulted in a 
saving in terms of states expanded, RCP always takes less 
CPU time. RCP also uses slightly more run-time memory 
in all examples, but always within a factor of 4 when 
compared to CP. In summary, RCP works better than CP 
in all cases where the critical path length is not optimal, 
which is typically the case in real-world (non-artificial) 
problems, where it is highly probably that constraints other 
than precedence constraints play a major role in dictating 
the total project duration. Therefore, RCP will result in 
better performance in most real-world cases. 

6 Conclusions and Future Work 

This paper has described an instance of a general three 
step problem-solving paradigm: abstract, solve, reconsti- 
tute. Certain details of the original problem are removed 
by abstraction. Next, the abstracted problem is efficiently 
solved. Finally, the abstracted details are reconstituted back 
into this solution. This reconstituted solution is then used 
as a guide for solving the original problem. We applied 
this paradigm to project scheduling problems and obtained 




a novel effective heuristic (the RCP heuristic). The general 
idea of reconstitution is to boost the informedness of an 
admissible heuristic by adding back previously abstracted 
details and maintaining efficiency. 

This approach as applied to project scheduling has several 
shortcomings. First, complex project scheduling problems 
often involve resource constraints with fixed limits for each 
job, typically specifying the number of fixed resource units 
that cannot be exceeded, rather than the absolute resource 
constraints as in our model; it is not clear to us how to recast 
such resource constraints as mutual exclusion constraints. 
However, Davis and Heidom [3] show a branch-and-bound 
solution to the problem. They describe a preprocessor 
algorithm that expands a job with duration k into a sequence 
of k unit duration jobs each successively linked with a 
“must immediately precede” precedence relation. After this 
expansion, a standard branch-and-bound project scheduling 
algorithm can be run. Unfortunately, such expansion can 
result in enormous project networks in projects with long 
duration jobs. 

A second shortcoming is that not all scheduling con- 
straints can be recast as precedence constraints. For exam- 
ple, a constraint that a particular job must start only after 
a certain time cannot be recast as a precedence constraint 
Effective admissible heuristics that reflect such general con- 
straints would be an important contribution to scheduling. 

Finally, although this paper has described a method for 
generating better admissible heuristics from existing ones, 
the process of discovering heuristics such as the RCP 
heuristic is far from automatic. We arc currently extend- 
ing this method to job-shop scheduling problems of the sort 
described in [5], In a job-shop problem, n jobs arc to be 
scheduled on m machines with varying durations per job 
per machine. We hope to develop a set of general princi- 
ples that practitioners in the scheduling field can follow to 
derive effective heuristics and eventually to automate the 
discovery process. 
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Mutual Exclusions are NP-Hard 

Finding a minimum duration schedule for a project graph 
with only mutual exclusion constraints and unit length job 
duration is equivalent to solving a graph coloring problem. 
In the project scheduling problem, the object is to partition 
jobs into a minimum number of sets such that each job is 
in exactly one set and no two jobs in a set have a mutual 
exclusion edge between them. Since all jobs in each set 
can be scheduled in parallel, the final schedule’s duration is 
simply the number of sets. In the graph coloring problem, 
the object is to color the nodes of a graph such that no two 
nodes connected by an edge have the same color and the 
minimum number of colors are used. Since there is a 1-1 
correspondence between the two problems and the graph 
coloring problem is NP-Hard, so is the project scheduling 
problem with mutual exclusion constraints. Furthermore, 
since resource constraints can be recast as mutual exclusion 
constraints, the problem of scheduling with resource con- 
straints is also NP-Hard and adding non-unit length job du- 
rations only makes the problem harder. Notice that adding 
precedence constraints will not affect this result. We thank 
Charles Martel for suggesting the basic idea behind this 
proof. 
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Abstract 

In this paper we consider a simple model of 
real-time scheduling. We present a real-time 
scheduling system called RTS which is based 
on Korf’s Minimin algorithm. Experimental 
results show that the schedule quality initially 
improves with the amount of look-ahead search 
and tapers off quickly. So it appears that rea- 
sonably good schedules can be produced with 
a relatively shallow search. 

1 Introduction 

Job shop scheduling is one of the most computation- 
ally intensive parts of flexible manufacturing systems. 
Scheduling in the real world is complicated by several 
factors including the resource contention, unpredictabil- 
ity of events, multiple agents with mutually conflicting 
goals, and the sheer combinatorial explosiveness of the 
task. In this paper, we simplify the real world scheduling 
problem to a great extent and focus exclusively on one 
aspect of the problem, namely its real-time character. 

This paper looks at detailed job shop scheduling at the 
level of individual machine operations. The scheduling 
problem is treated as assigning the job-steps to individ- 
ual machines and ordering them so that (a) the prece- 
dence and resource constraints are satisfied, and (b) the 
schedule is “good” in some measurable objective sense. 

Most approaches to scheduling are static in that the 
scheduling is done all at once and not during the pro- 
duction process. Static scheduling has several obvious 
drawbacks: First, optimal static scheduling is computa- 
tionally prohibitive in any realistic manufacturing sys- 
tem, which involves hundreds of jobs and machine oper- 
ations. Second, since the static scheduler has to make 
decisions based on predicted information, it has no way 
of recovering from incorrect predictions even after they 
were proved wrong. Thus, it is unable to readjust to 
or recover from changes in the production environment, 
including machine failures, new jobs, or machine delays. 

Real-time scheduling prevents the above two pitfalls of 
static scheduling by requiring that after every constant 
time, some real world action is taken. This not only 
prevents the system from losing itself in a combinatori- 
ally explosive search space, but also makes it possible to 


continually readjust to the changing environment. 

In this paper we present a system called RTS (Real- 
time Scheduler) which uses the Minimin algorithm of 
Korf [Korf, 1990] to do real-time scheduling. Minimin 
is similar to the Minimax algorithm extensively used 
in games. We view scheduling as a state space search 
where states represent partial schedules. Minimin per- 
forms a fixed depth look-ahead search from the initial 
state, and applies a heuristic evaluation function to the 
partial schedules at the leaves of the search tree to esti- 
mate the cost of the schedule. This value is backed up 
to the root of the tree and the system takes the most 
promising scheduling action, i.e., it assigns a job-step 
to a machine which leads to a schedule with the best 
estimated cost. 

Since RTS relies on heuristic estimates, the schedules 
the system produces are not guaranteed to be optimal. 
However, our experimental results show that the sched- 
ule quality initially improves with the amount of look- 
ahead search and tapers off quickly. So it appears that 
reasonably good schedules can be produced with a rela- 
tively shallow search. We conclude that our approach to 
real-time scheduling based on Minimin is promising and 
can be extended in several directions, including learn- 
ing better evaluation functions, and doing variable depth 
search. 

2 Previous Work 

One approach to scheduling is based on expert systems 
[Fox and Smith, 1984]. However, expert systems ap- 
proach to scheduling seems inadequate because of the 
dynamic nature of the scheduling problem, which is due 
to changes to job loads, availability of machines and la- 
bor, introduction of new machines and manufacturing 
processes, changes in the inventory space, etc. For this 
reason, there are no experts in this domain, and even if 
there were, they would be quickly outdated [Kempf et 
al., 1991]. 

Many Al-approaches to scheduling are constraint- 
based [Fox, 1987, Sadeh, 1991, Smith et al., 1986, 
Zweben and Eskey, 1989]. Here scheduling is viewed 
as finding a schedule (assignment of machines to various 
job-steps) which satisfies a set of constraints, including 
precedence relationships between job-steps and global re- 
source constraints. However, most of these approaches 
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assume a static scheduling problem, and are not easily 
adaptable to real-time scheduling. 

Traditionally, the “dynamics” of the manufacturing 
process is handled by local greedy dispatch rules [Voll- 
mann et al., 1988]. One dispatch rule, for example, rec- 
ommends to schedule the job with Least Processing Time 
(LPT) first, while another rule uses Earliest Due Date 
(EDD) to prioritize jobs. While computationally cheap, 
such local dispatch rules are too short-sighted, and do 
not guarantee efficient schedules except in very special 
cases [Kempf et al., 1991]. 

In summary, static optimal scheduling is computa- 
tionally prohibitive and is not sufficiently responsive to 
change. On the other hand, local dispatch rules are too 
short-sighted to be generally effective. The expert sys- 
tems approach is plagued by the dynamics of the schedul- 
ing problem and paucity of experts. In this paper, we 
propose an approach based on real-time search which 
attempts to address each of the above problems. 

3 Problem Description 

The problem we address can be characterized as schedul- 
ing the job-steps in a set of jobs on various machines in 
real time. We make the following assumptions. 

1. Each job consists of a sequence of job-steps that 
must be performed serially. 

2. There may be several machines of each machine 
type. 

3. Each job-step requires a machine of a particular 
type to perform it. 

4. Each machine can only process one operation at a 
time. 

5. Each job may require the same machine (or machine 
type) more than once. In other words, we have a 
“job shop” situation rather than a “flow shop” sit- 
uation [Vollmannet al., 1988]. 

6. The machine type required for each job-step and the 
time for each job-step is known in advance. 

7. The real-time constraint means that the time for 
deciding which job-step to schedule next is “small,” 
and should not depend on the number of jobs and 
job-steps. 

For example, each job in Figure 1 consists of a se- 
quence of job-steps. The task of the scheduler is to in- 
crementally add new job-steps to the current machine 
queues. As the machine queues are filled from the back 
by the scheduler, they are emptied from the front by the 
machines executing the job-steps. In addition, the job- 
step must wait until its predecessor job-step in its job 
is executed. For example, in Figure 1, job-steps S-ll, 
S-22, and S-42 are in the queue for machine Ml in that 
order. In addition, S-ll, S-12, S-13, and S-14 must also 
be processed sequentially, because they are all part of a 
single job. 

Since scheduling is done while the jobs are getting ex- 
ecuted, the scheduler has only a limited time to decide 
what job-step to schedule next, and on what machine. 




Machine Queues 


Scheduler 


Figure 1: Scheduler assigns job-steps to machine queues. 


4 Scheduling as State Space Search 

We formulate the scheduling problem as a state space 
search problem. States in the scheduling task correspond 
to partial schedules represented as queues of job-steps for 
the machines. The search problem is characterized by an 
initial state, where there are no jobs scheduled, and a fi- 
nal state, where all the jobs are scheduled. In any state, 
there are several alternative assignments of the job-steps 
to machine queues. A job-step is “ready” when all its 
precedent job-steps have completed. Scheduling opera- 
tors or “moves” assign job-steps to one of the machines 
of the required machine type. In other words, they can 
be placed on any one of the possible queues of the ap- 
propriate machine type. Each such placement creates 
a new state. The scheduling problem is to find a best 
assignment of job-steps to machine queues according to 
some measure of goodness (objective function). For ex- 
ample, we may use the total time for the schedule or the 
sum of the inventory and shortage costs as an objective 
function. 

The static scheduling problem corresponds to finding 
the best path in the state space from the initial state 
to a final state. However, static scheduling suffers from 
the combinatorial explosion due to deep searches and is 
not sufficiently responsive to the dynamics of the man- 
ufacturing domain. In the following, we describe our 
approach to scheduling that addresses these problems. 

4.1 Minimin search 

Our approach to scheduling consists of a real time search 
method called “Minimin search” [Korf, 1990]. Minimin 
is similar to minimax search in two-person games, ex- 
cept that instead of alternating Min and Max nodes, the 
search tree only contains Min nodes. 

Minimin works by a fixed depth look-ahead search fol- 
lowed by a real-time action. The search terminates after 
a small depth called “search horizon,” after which the 
leaves of the tree are evaluated using a heuristic evalu- 
ation function. The evaluation function applied at the 
leaves estimates the minimum total cost of any solution 
that begins with a partial path ending with that leaf. 
It is backed up to the root using the Min function. In 
other words, the value of any node is the minimum of all 
the values of its children, and the move that results in 
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that value is the “best move.” After searching for a fixed 
look-ahead depth, Minimin chooses the first best move, 
executes it, updates the state and once again starts look- 
ahead search from that point. 

The “knowledge” of the Minimin algorithm lies in its 
heuristic evaluation function /. The more closely it fol- 
lows the real cost of the solution, the more optimal the 
algorithm’s current decision is going to be. An evalua- 
tion function is “admissible” if it never overestimates the 
real cost of a solution. An evaluation function is mono- 
tonic, if its value is monotonically non-decreasing along 
any single path of the search tree. 

When the evaluation function of the Minimin search 
is monotonic, it is amenable to an effective branch and 
bound technique called a-pruning. a-pruning works by 
pruning the branches whose estimated cost is more than 
the current best estimated cost. Like a-/? pruning, a- 
pruning is guaranteed to preserve the outcome of the 
look-ahead search. 

Each time the Minimin algorithm is called it returns 
the best next state and its estimated evaluation. The 
main program then takes the corresponding action in 
the “real world” and updates its current state to this new 
state. After this, the program repeats its cycle again by 
calling the Minimin algorithm. 

4.2 Real-time Scheduling 

We noted that in Scheduling the states correspond to 
partial schedules and operators correspond to scheduling 
actions. In order to complete the mapping of the real- 
time scheduling problem to Minimin search, we need to 
specify how a schedule is evaluated. 

Several optimality criteria might be used to evaluate 
the schedules. One of the criteria is the sum of the short- 
age and the inventory costs. Another criterion is the to- 
tal length of the schedule from the beginning to the end, 
also called “make-span.” In our system, we currently 
use the make-span criterion to evaluate schedules. The 
smaller the make-span, the better the schedule. In Min- 
imin search, the cost of the schedule must be estimated 
after only a small number of steps are scheduled, i.e., 
much before the full schedule is known. To do this effec- 
tively, we should necessarily rely on heuristic estimates 
of the schedule cost. A good heuristic evaluation func- 
tion must approximate the optimality criterion as closely 
as possible. 

As discussed earlier, there is an implicit precedence 
relationship between the job-steps in the same machine 
queue, and between the job-steps that belong to the same 
job. For any job-step s, let PRE(s) be the set of job- 
steps which are immediate predecessors of s, in that they 
need to be performed before s is done. In Figure 1, 
PRE{ S-12) = {S-ll, S-21). 

Our estimate of the make-span is done as follows: first, 
we compute the time T, by which each machine Mi fin- 
ishes its current queue. Assuming that the expected time 
ET(s) for each job-step s is known in advance, this can 
be calculated exactly. Let the expected start time and 
the expected finish time of a job-step s be denoted by 
ES(s) and EF(s) respectively. The expected start and 
finish times of any job-step can then be calculated using 


Minimin(Curren<Sta<e, depth , a) 

If depth = Searchfforizon return (/(Current State))] 
%Alpha Pruning 

If /(Current State) > a return (a -|- 1) 

5 := job-steps which are “ready” ; 

M {m \3seS that needs a machine of m's type } 
Pick m € M s.t. its current queue finishes earliest. 

For each job-step s E S which matches m's type, Do 
Begin 

NewState := Assign(s,m); 

Val := Minimi^NewState, depth + l,a); 

If Val < a 
Begin 
a := Val; 

BestN ext State := NewState; 

End; 

End; 

Return(a, Best N extState); 

End Minimin; 


Table 1: Minimin Applied to Scheduling 


Let T{ be the time by which machine Mi finishes the last 
job-step in its current queue. The goal of the Minimin 
search is to find the best next job-step to add to the cur- 
rent queues by doing a look-ahead search of fixed depth 
in the space of partial schedules (machine queues). 

A job-step is considered “ready” if all its predecessors 
are either already executed or present in one or the other 
of the machine queues. At any given state, RTS first 
filters its machines by discarding those machines which 
do not have any ready job-steps waiting for their machine 
type. It then chooses the machine A/, which is expected 
to finish its queue the earliest, i.e., with a minimum 7J, 
and considers scheduling various job-steps on it. Each 
“ready” job-step s whose type matches that of machine 
Af,* is a possible choice. For each such possible choice, 
Minimin creates a new state by assigning s to Mi , and 
updates the expected finish time of M, ’s current queue 
using the above recurrence relations. RTS proceeds in 
depth first search in this manner until it reaches the 
search horizon. 

At the leaves of the look-ahead search tree, the total 
time required to complete the remaining schedule must 
be estimated. Since none of the job-steps in the remain- 
ing schedule is assigned to a machine yet, their expected 
finish time cannot be exactly estimated. It is here that 
we rely on a heuristic lower bound. 

Let Tk be the maximum of 7} of all machines Mi 
of type K. Let Wk be the total work remaining on 
machines of type /£, i.e., the total expected time of all 
job-steps that need a machine of type K . Assume also 
that there are Nr machines of type AT. Ignoring all the 
precedence constraints between the job-steps, the work 
remaining on machines of type K can be distributed as 


the following recurrence relations. 

ES(s) = Max rePRE ( s ){EF(r)} 
EF(s) = ES(s) + ET(s) 
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follows. First fill each machine of type K until they 
reach the level 7/f. This does not increase the make- 
span because it anyway takes that long to wait for the 
current queue to finish. This reduces the remaining work 
on machine of type K to Wk “ E<{Tjc - 7}}, which may 
be distributed evenly among all the machines of type 
K in the best possible case. Hence, we observe that the 
time for completing the schedule must at least be as high 
as the following two bounds. 

1. (t k + id ) 

2. Maxj eJol ,(E, eJ FT(e) + Min(Ti)) 

The second lower bound above is obtained by noting 
that the job-steps in a single job should be executed 
sequentially. To the total time needed to execute any job, 
the minimum expected finish time of all machine queues 
is added. The finish time of the schedule is estimated to 
be the maximum of the above two hounds. 

The above evaluation function is both admissible 
(never overestimates the true cost) and monotonic 
(monotonically non-decreasing along any path). This 
follows because, adding job-steps to the machine queues 
can only increase but never decrease the delays, by intro- 
ducing more constraints. Since each step in the search 
adds a new job-step to the queues, the expected comple- 
tion time is monotonically non-decreasing. The mono- 
tonicity is exploited by RTS by maintaining the current 
estimate a of the best schedule and evaluating / at inter- 
nal nodes even before the search horizon is reached. Be- 
cause / is monotonically non- decreasing, any path whose 
current estimate of the schedule cost exceeds the current 
value of a is guaranteed to yield only a worse solution 
and hence need not be pursued further. In other words, 
or-pruning would not sacrifice solution quality. 

The estimated time for completion is backed up to the 
internal nodes from the leaves and finally to the root of 
the look-ahead search tree. The path that promises the 
lowest make-span is considered the best. An assignment 
of the first job-step in this path is made as suggested by 
this path. After this assignment, which corresponds to 
an action in the “real world,” RTS takes a fresh look at 
its environment and starts a new cycle all over again. 

4.3 Experimental Results 

The problem specification is a 5-tuple. It consists of the 
number of jobs, the number of machines, the number of 
types of machines (this has to be less than the number 
of machines) and two numbers which specify the upper 
bounds on the number of steps for any job and the pro- 
cessing time for any step. Number of steps for each job 
is generated randomly, bound by the upper bound given 
in the problem specification. Each job-step is randomly 
assigned a machine type. Each job-step is also assigned 
some processing time randomly, bound from above as 
given in the problem specification. 

We tested RTS on a sample of 39 randomly generated 
problems. Each problem had about 4-6 machines divided 
into 3-4 types, and 4-6 jobs each of which had about 5 
steps, each step taking up to 6 units of time. We then 
ran the system with different look-ahead depths, and 
measured the total time to execute the whole schedule 
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Figure 2: Solution quality improves with search horizon. 

(make-span). We plotted the search horizon on the X- 
axis and the average make-span on the Y-axis. 

The results show that the solution quality generally 
improves with search horizon, as expected. This tradeoff 
of search for solution quality was very favorable in the 
beginning, and tapered off toward the end. Although 
deeper searches resulted in better solutions on the whole, 
they also required exponentially larger number of nodes, 
taking exponentially longer time. In our context, the 
results indicate that a search horizen of 7 to 10 would 
achieve reasonably good schedules without extravagant 
search. 

In general, it appears that a shallow look-ahead search 
would suffice to improve solution quality in this domain, 
which means that deep expensive searches may not be 
needed. 

5 Future Work 

The work reported here is preliminary and a lot remains 
to be done to make the ideas more practical and appli- 
cable in a real-world setting. A few of the promising 
directions to pursue are listed below. 

Reactivity: One of the major reasons for building 
“real-time” systems is that they are more responsive 
to changes in their environment. This is especially 
crucial in the manufacturing domain, where unex- 
pected events such as machine break-downs and 
tool failures are common. We believe that our sys- 
tem would respond better to such changes than a 
static scheduler. Indeed, it is possible to completely 
change the machine and job configuration before ev- 
ery cycle of the Minimin algorithm. The system 
should still be able to make locally optimal decisions 
with respect to its changed configuration. However, 
we expect that the system’s behavior degrades grad- 
ually as the dynamics in the system configuration 
increases. It might also be expected that the use- 
fulness of the look-ahead search decreases with in- 
creased dynamism. These hypotheses need to be 
experimentally verified. 

Variable Depth Search: We assumed that the search 
horizon is fixed. However, this need not be the 
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case, and it is possible to change the search horizon 
across problems and even within the same problem. 
For example, a method called "Singular Extensions” 
proved very effective in game domains by focusing 
the search along narrow paths which appear signif- 
icantly more promising than their nearest competi- 
tors [Anantharaman et al., 1990]. It seems possi- 
ble to adapt this technique to real-time scheduling 
and search deeper at places in the search tree which 
appear promising. We can also add the iterative- 
deepening capability to Minimin, so that more time 
can be spent searching for a better schedule if time 
is available [Korf, 1985]. This also makes it an any- 
time algorithm in the sense of [Dean and Boddy, 
1988], in that it can be interrupted at any time dur- 
ing its computation and asked to schedule the next 
job-step. The utility of the system’s decisions is ex- 
pected to increase with the time available to make 
the decision. 

Learning: The performance of the system at a given 
search horizon depends mostly on the goodness of 
the evaluation function used to estimate the opti- 
mality of the schedule. Although our current eval- 
uation function performed fairly well on the prob- 
lems that we tested it on, it does not take into ac- 
count factors such as bottleneck resources, which are 
crucial for a good scheduler. However, it is time- 
consuming and laborious to encode sophisticated 
evaluation functions. Besides, good evaluation func- 
tions are sensitive to the scheduler’s environment, 
and hence may not be generally effective. Hence 
we plan to apply machine learning to learn effec- 
tive evaluation functions [Lee and Mahajan, 1988], 
There have already been some machine learning 
methods applied to scheduling domains [Kim, 1990, 
Shaw et al., 1990]. We think that significant im- 
provements beyond current scheduling techniques 
can be achieved using machine learning. 

6 Summary 

In this paper we described a real-time scheduling sys- 
tem based on the Minimin algorithm and showed that 
it is effective and capable of producing good schedules 
with reasonably small effort. In particular, we showed 
that the schedule quality improves with increased look- 
ahead, confirming some of the results of Korf on Real- 
time Search in the scheduling domain. The future work 
includes evaluation function learning, variable depth 
searches, and demonstration of the reactivity of the sys- 
tem. Although much remains to be done, the prelimi- 
nary results reported in this paper appear promising. 
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1 Introduction 

Making observations through telescopes is an activity of 
central importance to NASA. Whether a telescope is lo- 
cated on the Earth, is in orbit around the Earth as a 
satellite, is located on the moon, or is even on another 
planet, it presents an exciting and sometimes unique op- 
portunity for gathering data about various astronomical 
phenomena. Telescopes have always been a scare re- 
source, and astronomers have had to make do with ex- 
tremely limited access. Further, an astronomer has been 
expected to be physically present at a telescope in order 
to gather data. Restricted access and local operation 
have limited the amount of data that can be gathered, 
and thus have directly contributed to fewer scientific re- 
sults than might otherwise be expected. 

Recent work by the Fairborn Observatory and Auto- 
Scope Corporation has freed astronomers from the need 
to be physically present at the telescope site. These orga- 
nizations, working with astronomers, have designed and 
built control systems and associated hardware for the 
management and control of photoelectric telescopes; for 
a review of these Automatic Photoelectric Telescopes, or 
APTs, see Genet and Hayes (1989). While existing au- 
tomation deals primarily with photoelectric telescopes, 
other sorts of telescope and other sorts of science are cur- 
rently under investigation. The key point is that there 
is a perceived need, within the cutronomy community , 
that the automation of local telescope control is desir- 
able. Existing automation does not address all needs of 
all astronomers, but it does provide an excellent start- 
ing point. The eventual goal is what we call a “simplified 
management structure”. The term refers to an approach 
to the management and control of telescopes that mini, 
mizes the number of people that must come between an 
astronomer’s scientific goals and the telescopes required 
to realize those goals. A simplified managementlitruc- 
ture requires significantly more sophisticated telescope 

automation than is currently possible. 

The Entropy Reduction Engine (ere) project, carried 
out at the Ames Research Center, is focusing on the 
construction of integrated planning and scheduling sys- 
tems. Specifically, the project is studying the problem 
of integrating planning and scheduling in the context of 
closed-loop plan use. The results of this research are 
particularly relevant when there is some element of dy- 


namism in the environment, and thus some chance that 
a previously formed plan will fail. After a preliminary 
study of the APT management and control problem, we 
feel that it presents an excellent opportunity to demon- 
strate some of the ERE project’s technical results. Of 
course, the alignment between technology and problem is 
not perfect, so planning and scheduling for APTs presents 
some new and difficult challenges as well. 

This paper presents an argument for the appropriate- 
ness of ERE technology to the planning, scheduling, and 
control components of management. The paper is 
organized as follows. In the next section, we give a brief 
summary of the planning and scheduling requirements 
for APTs. Following this^ in section 3, we give an ere 
project precis, couched primarily in terms of project ob- 
jectives. Section 4 givef a sketch of the match-up be- 
tween problem and technology, and section 5 outlines 
where we want to go with this work. 

' J4 . . j / t 

2 apt problem sulnmary - r / ’ 

An Automatic Photoelectric Telescope is a telescope con- 
trolled by a dedicated computer for the purpose of gath- 
ering photometric data about various objects in the sky. 
While there are many sorts of photometric techniques, 
we focus on the technique known as aperture photom- 
etry, An excellent overview of aperture photometry is 
given by Hall and Genet (1988). In aperture photometry, 
and for current purposes, a group is the primitive unit 
to be scheduled. A group is a sequence of telescope and 
photometer commands defined by an astronomer. Any 
given astronomer has certain scientific goals, and he or 
she uses the group as the primary unit of instruction to 
an APT in order to achieve those goals. The language 
used to define groups is called atis (for Automatic Tele- 
scope Instruction Set); ATIS is an ASCII-based language 
for communicating with apts (the de facto standard). 

The communication process between astronomer and 
APT proceeds roughly as follows. First, an astronomer 
who wishes to use an APT forms a set of groups consistent 
with his or her scientific goals. These groups are written 
specifically in terms of a given telescope: since each tele- 
scope can vary slightly (instruments, optical characteris- 
tics, mechanical characteristics, location on the Earth), 
groups must be formulated in a telescope-specific man- 
ner. For any given APT there is a single person who 
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acts as a central clearing-house for usage requests; such 
a person is known in the vernacular as the apt’s Prin- 
cipal Astronomer \ or PA. Thus, once an astronomer has 
assembled his or her set of ATIS groups, they package 
the groups off to the appropriate PA. The pa collects to- 
gether such sets from a variety of astronomers, attempts 
to ensure that the telescope is not overloaded, and then 
sends the complete set of groups off to the correct tele- 
scope. Actual communication between PA and APT is 
carried out by using personal computers, modems, and 
phone lines, but the particular technology isn’t critical 
for the current discussion. The important aspect of the 
communication is that the pa can be located anywhere 
on the planet (in principle), and need only have access 
to an appropriate communication link. 

The PA sends a set of groups to an apt, with the in- 
tention that these groups should be run for some time; 
eventually, the PA requests from the telescope the re- 
sults that have been obtained under the execution of 
the given groups. The elapsed time varies, and depends 
on the telescope, the groups, the PA, and a variety of 
other factors. Of course the goal is to worry the as- 
tronomers (and the pa) as little as possible about the 
picayune details of day-to-day telescope management. 
Thus, the telescope is often left alone for significant peri- 
ods of time (weeks, perhaps months). However long the 
telescope operates unattended, it is eventually asked for 
data, and this is returned to the pa as a “results file”. 
The results file is also in the ATIS language, and it con- 
tains the groups that were executed, relevant observing 
parameters to help with data reduction, and the actual 
data obtained from the observations. The PA breaks this 
results file into the pieces that are relevant for the as- 
tronomers and sends each astronomer the results of his 
or her requested observations. Thus the cycle of group 
submission, compilation, execution, and data return can 
begin again when the astronomers discover that the data 
they’ve been given doesn’t really tell them what they 
wanted to know (such are the joys of real science). 

Of course, the interesting part of this process is the 
part that we’ve completely ignored so far; that is, the 
process by which the groups are accepted and executed 
by the local telescope controller. This is the interest- 
ing part, and it is with respect to this process that our 
planning and scheduling work can make a real differ- 
ence. Currently, a program called ATIS cope manages the 
execution of a file of groups. ATiscope runs locally at 
the given telescope, using observatory and telescope sen- 
sors to determine when to execute the provided groups. 
ATiscope has a variety of responsibilities, but we focus 
specifically on only one of these; namely, group selection. 

At the core of ATiscope is a test that attempts to find 
a “currently” executable group. Roughly, a group is ex- 
ecutable if the logical preconditions established by its 
astronomer-creator are met. Typically, these precondi- 
tions relate to the current date and time and to whether 
the moon is up or down. Additionally, an astronomer 
can specify a group priority , used by ATiscope to sort 
the groups in order of importance. There are other 
pseudo-preconditions that have to do with frequency of 


group execution, but we can safely ignore these for now. 1 
Roughly, the core of ATiscope is a sense-check-execute 
loop. In sensing, all relevant environmental parameters 
are determined (date, time, moon status). ATiscope next 
checks to see which of the various possible groups are en- 
abled according to the match between the current sensor 
values and the astronomer-provided preconditions. Let’s 
call the set of groups that pass this matching test the en- 
abled groups. The set of enabled groups is winnowed by 
the application of group selection rules. These rules ex- 
press heuristic knowledge relating to the wisdom of exe- 
cuting any particular group before any other. In schedul- 
ing parlance, this scheme is sometimes called heuristic 
dispatch , since at any point in time, some task (here, a 
group) is “dispatched” for execution, and the selection 
of a task is determined, purely locally, by the applica- 
tion of some domain-specific heuristics. The information 
content of the heuristics used by ATiscope isn’t critical 
for the current discussion (however, see Genet & Hayes, 
1989, pp. 207-210). In the current context, heuristic 
dispatch is used to transform the set of enabled groups 
into a (hopefully) single group that is executed. If the 
heuristic group selection rules fail to winnow the set of 
enabled groups down to a single candidate, then the first 
group in the given list is selected (this, however, almost 
never happens, as the group selection rules normally pro- 
duce a single preferred group). Following selection, the 
lucky group is executed, at which point telescope con- 
trol is largely surrendered to the astronomer who wrote 
the group. Of course, there are safety checks to ensure 
that the astronomer’s commands don’t damage equip- 
ment, but if the commands are well-behaved (and if the 
weather cooperates), group execution finishes normally, 
and ATiscope is free to perform another iteration through 
its sense-check-execute loop. 

How well does ATiscope do, in terms of schedule qual- 
ity, by using this heuristic dispatch technique? One way 
of answering this question is to recall the old adage about 
an incredible dancing dog: the question of the quality of 
the dog’s dancing needn’t really be raised; one should in- 
stead be happy that the dog dances at all. ATiscope does, 
of course, provide an acceptable level of performance for 
some astronomers. There is no question, however, that 
the level of telescope performance can be dramatically 
improved by better group scheduling. With the heuris- 
tic dispatch technique, all decisions are local in the sense 
that no temporal look-ahead is performed to evaluate 
the ramifications of executing a given group. The sys- 
tem also has no memory of what it has done on previ- 
ous nights, so groups cannot be selected with respect to 
some desired frequency of execution. Other scheduling 
techniques, such as those based on temporal projection 
(Drummond & Bresina, 1990), consider the impact of a 
given action by looking ahead in time to see how the 
current local choice impacts global objectives. Look- 
ahead is only sensible when astronomer objectives can 
be clearly and precisely formulated. Assuming that this 
can be done, it seems clear that a look-ahead scheduler 

x The main factors that influence frequency of execution 
are a group’s probability and number of observations ; see 
Genet & Hayes (1989), p. 208. 
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can outperform the current ATlScope heuristic dispatch 
method. ATlScope, however, provides us with an ex- 
isting level of performance against which all would-be 
contenders can be gauged. 

3 ERE goals 

The design of systems that can synthesize plans has been 
a long standing research topic in the field of Artificial In- 
telligence (AI). Such systems, called planners , are given 
a description of the problem at hand, and can synthe- 
size a plan to solve that problem. Of course, a plan 
is merely a specification of a solution, and so must be 
executed to actually solve the given problem. Various 
sorts of "execution system” are possible; for instance, 
a plan might be executed by a manufacturing system, 
by a group of people, or by a robotic device; all that 
is required is a system that is capable of instantiating 
the plan’s actions and thus producing the desired re- 
sult. The design of these automatic planners has been 
addressed in AI since its earliest days, and a large num- 
ber of techniques have been introduced in progressively 
more ambitious systems over many years. In the AI re- 
search branch at NASA Ames, the Entropy Reduction 
Engine (ere) project is our focus for extending these 
classical techniques in a variety of ways. In this sec- 
tion we present the ERE project’s overall goals; for more 
detail on the architecture itself, see Bresina & Drum- 
mond (1990), Drummond & Bresina (1990a, 1990b), and 
Drummond, Bresina, and Kedar (1991). 

The Entropy Reduction Engine project is a focus for 
research on planning and scheduling in the context of 
closed-loop plan execution. The eventual goal of the ERE 
project is a set of software tools for designing and deploy- 
ing integrated planning and scheduling systems that are 
able to effectively control their environments. To pro- 
duce such software tools, we are working towards a better 
theoretical understanding of planning and scheduling in 
terms of closed-loop plan execution. Our overall project 
has two important sub-goals; first, we are working to 
integrate planning and scheduling; second, we are study- 
ing plan execution as a problem of discrete event control 
Let’s consider these complementary goals in a bit more 
detail. 

Integrate planning and scheduling. Traditional AI 
planning deals with the selection of actions that are rel- 
evant to achieving given goals. Various disciplines, prin- 
cipally Operations Research, and more recently AI, have 
been concerned with the scheduling of actions; that is, 
with sequencing actions in terms of metric time and met- 
ric resource constraints. Unfortunately, most of the work 
in scheduling remains theoretically and practically dis- 
connected from planning. Consider; a scheduling system 
is given a set of actions and returns, if possible, a sched- 
ule composed of those actions in some specific order. If 
the scheduler cannot find a satisfactory schedule, then it 
simply fails. The business of planning is to select actions 
that can solve a given problem, so what we need is an 
integrated planning and scheduling system to overcome 
the problems of scheduling alone. An integrated plan- 
ning and scheduling system would be able to consider 
alternative sets of actions, unlike the stand-alone sched- 


uler, which is unable to deviate from its given action set. 
We are working towards such an integrated system by 
incrementally constructing a unified theory of planning 
and scheduling that can be computationally expressed 
as practical software tools. 

Study plan execution as a control theory problem . 
Most planning and scheduling work assumes that the job 
of the automatic system is done when a plan or schedule 
has been generated. Of course, one of the first things 
that you learn about plans is that they are rarely ever 
perfectly predictive of what will happen. As Dwight D. 
Eisenhower observed, "Plans are nothing, planning is ev- 
erything”. We agree with this view, since it tells us that 
the importance of planning does not lie in the existence 
of a single plan, but rather in a system’s ability to re-plan 
and predict ively manage plan execution failures in light 
of feedback from the environment. In the ere project, 
we view plan execution as a problem in discrete event 
control; specifically, we formalize a plan as a simple type 
of feedback controller, and this gives us a new view on 
plan execution. Traditionally, plans have been executed 
by executing each component action in sequence. Our 
plans are functions that map from current sensor values 
and a desired goal into a set of acceptable control ac- 
tions. The interpretation of the function is that any of 
the actions, if executed in the current situation, consti- 
tute an acceptable prefix to a sequence of actions that 
eventually satisfies the goal. 

4 The match, in the abstract 

The previous two sections have, in rough terms, ex- 
plained the APT problem and overall ere project goals. 
In this section, we consider how ERE technology promises 
to address key APT planning and scheduling issues. This 
section is optimistic and is, by necessity, "promissory”, 
in the sense that some of what we suggest has yet to be 
rigorously demonstrated. This section reflects what we 
currently perceive as opportunities for using ere tech- 
nology on the APT planning, scheduling, and control 
problem. 

First, the obvious: ERE is an architecture for produc- 
ing systems that look ahead into the future, and by 
so doing, choose actions to perform. We feel that the 
ere architecture is well-suited to the apt planning and 
scheduling problem in this regard. ATlScope currently 
does no look-ahead, so assuming that our system does, 
it should be able to produce better schedules. In fact, 
one of our research interests is the relationship between 
the cost of looking ahead and the increased "quality” of 
the system’s actual behavior. In the apt domain, the 
quality of system behavior is determined by the amount 
and quality of the data returned by a given set of obser- 
vations, and by the fairness of telescope allocation to the 
various astronomers’ groups. Now ATlScope currently 
achieves a particular level of quality, and we expect to be 
able to increase this through some amount of look-ahead. 
But at what cost? When does look-ahead actually give 
rise to better system performance? ATlScope, while per- 
haps not producing the highest quality behavior, does so 
with great alacrity. A scheduling system that does any 
amount of look-ahead consumes more computational re- 
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sources than ATlScope, so the behaviors it produces had 
better be worth the increased cost. Of interest here is 
the impact of environmental factors on the underlying 
requirement for look-ahead: if the environment is com- 
pletely predictable, and if a great deal of time is available 
in advance, then a scheduler that looks ahead extremely 
far into the future is apparently what’s required. How- 
ever, if the environment can change quickly, and change 
in unpredictable ways, then much of the work done by a 
look-ahead scheduler is wasted. The correct balance be- 
tween look-ahead and heuristic dispatch is truly a func- 
tion of the domain. There has been little empirical study 
of this issue in general, and we feel that APT planning 
and scheduling provides an excellent test case. 

We have an algorithm for incremental, “anytime”, 
planning (Drummond & Bresina, 1990) that we thinks 
will be useful in the APT context. While our algorithm 
has only been tested on relatively simple planning prob- 
lems, we think that many of the underlying ideas transfer 
to scheduling as well. The essential idea is as follows: if 
a system has a limited amount of time to plan, and, hav- 
ing planned, is allowed to plan no further, then it makes 
sense for the system to make the best use of the available 
time by incrementally improving its current plan until 
time runs out. Our algorithm, called traverse and robus - 
tify, does this. It uses information about possible execu- 
tion outcomes to predict ively patch errors, before they 
actually occur. By doing this the algorithm attempts 
to maximize the probability that the plan it finds will 
satisfy the user’s objectives. This algorithm promises to 
be useful in a scheduling context, and apts provide an 
appropriate test-domain. If we think of the scheduler as 
running during the day (remote from the telescope, in 
the PA ’8 place of work), and imagine that the finished 
schedule will be shipped to the telescope for overnight 
execution, then one would like the schedule produced to 
be of the highest possible robustness given the available 
time, so our algorithm seems appropriate. 

5 Objectives 

First and foremost, we must define an appropriate ob- 
jective function for APT observation schedules. How well 
can this objective function be formalized? How will we 
notate it? That is, what will be our language for writing 
down the objective function? For the problems we have 
studied to date, our language of behavioral constraints 
has been adequate. The current behavioral constraint 
language allows a user to give arbitrary conjunctions and 
disjunctions of predicates that must be maintained true 
(or prevented from being true) throughout an interval 
of time (see Drummond & Bresina, 1990, for more de- 
tail). Is this language adequate for expressing the sorts 
of goals that astronomers have? Will we need to drop 
into the language of arbitrary mathematics? Of course, 
this is what most of decision analysis does, so should we 
expect to do any better? We hope to devise a new sort 
of behavioral constraint language, specifically designed 
to allow astronomers to define APT observation schedule 
preferences. Even with such a specially-designed lan- 
guage, there’s a remaining second-order problem: the PA 
(or other user) must be able to define what constitutes 


a fair and equitable tradeoff of telescope and instrument 
allocation between different astronomers. Of course, we 
don’t want a person (the PA or other user) to have to 
specify the specific tradeoff for each given scheduling in- 
stance, but the general form of the tradeoff function used 
must be defined by a user. These and other interesting 
issues lurk in the vicinity of schedule objective functions. 

We are fortunate to have access to several APT experts. 
One expert is an original APT architect who has founded 
a firm to commercially produce APTs. The other experts 
are experienced photometric astronomers, one of whom 
is an active APT user and has acted as a principal as- 
tronomer in the past. It is our hope that by working 
directly with this diverse and experienced group of apt 
developers and users, we will be able to produce plan- 
ning and scheduling tools of use to a large number of 
photometric scientists. 

In the short term (6 months), we plan to produce an 
interactive scheduling tool for use by ourselves, with our 
APT user acting as a local domain expert. The tool 
will help a user analyze a given set of groups by in- 
teractively determining the best sequence in which the 
groups should be run, providing help with the selection of 
the best sequence, but leaving the user free to intervene 
should he or she so desire. The system will automati- 
cally compile out a set of group selection rules that will 
produce the desired set of group execution sequences. 
Essentially, our system will be used to compile a set of 
scheduling dispatch rules that are designed specifically 
for the target set of groups, to be run on the target tele- 
scope, for a particular night of observations. We have 
studied the problem in some detail and are confident 
that our existing techniques for compiling such rules will 
work on the APT problem (see Drummond, 1989). 

We have access to an APT simulator and will use this 
to evaluate our system’s evolving capabilities. Of course, 
the eventual goal of this research is to remove humans 
from the control loop, so this first short term objective 
might not appear to be a tremendous step forward. It 
is, in fact, best construed as a step “sideways”, prefa- 
tory to a giant leap forward. We will use our interactive 
scheduling tool to gain experience with the APT planning 
and scheduling problem; our eventual goal is to entirely 
automate the decisions still made by a human user. This 
first sideways step towards a decision support system is 
thus not an end in itself, but only a means to a bigger, 
more important end. 

In the medium term (1 year), we plan to produce 
a better, incremental scheduler designed to replace 
the ATlScope system. Our new scheduler would be 
based on experience gained with building our look-ahead 
scheduling decision-support system. Our scheduler, like 
ATlScope, would accept a set of groups from the pa (or 
various astronomers, thus freeing the pa entirely from 
any scheduling responsibilities), and would schedule and 
execute these in a flexible manner. This first prototype 
automatic scheduler would not provide a very sophisti- 
cated language of scientific objectives; instead, it would 
allow a user or users to specify a set of groups, and would 
attempt to better the current level of performance ob- 
tained by ATlScope by doing temporal projection (look- 
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ahead) and history recording (remember-behind). 

Our long term plan (2 years) is to extend the language 
of objectives to allow users to specify interesting scien- 
tific objective functions. The first test case would be a 
facility for filling out a desired light curve. Other test 
cases will be established in conjunction with our APT 
experts. The extra functionality offered at this stage of 
development will be that of planning , as opposed to pure 
scheduling . It is at this point that our system really be- 
gins to offer increased scientific power over that of the 
traditional ATlscope-style system. Until now, we have 
only sought to increase the “quality” of the group exe- 
cution sequences. Here, we seek to increase the expres- 
siveness of the language that is used by an astronomer 
to specify scientific objectives. 

Once individual APTs are routinely being used by re- 
motely located astronomers, with nearly all scheduling 
conflicts being resolved automatically, many new oppor- 
tunities arise. For instance, at this point it becomes 
practical to consider a network of relatively inexpensive 
telescopes, located around the world, which are able to 
provide continuous observation of astronomical objects. 
While possible now for exceptional events (supernova), 
the logistical overhead precludes wider practice. 

We are purchasing and intend to operate a 16-inch 
APT. This telescope will be located in northern Califor- 
nia, and will be made available to members of the sci- 
entific community, with the focus being on educational 
institutions. We will make our system available over the 
Inter Net, such that remotely located astronomers can 
simply Email request files to our system. Our system wiD 
accept a number of requests from various users, sched- 
ule them, and download the set of groups and group 
selection rules to the telescope. Users will receive their 
requested data via return Email or will be given access to 
an ptp site where their data may be recovered. This sys- 
tem will provide the first example of a totally automated 
telescope planning, scheduling, and control system. We 
plan to have the system operating totally autonomously 
as soon as possible. 

We hope that our demonstration of fully automatic 
telescope operations will serve as groundwork for new 
applications of simplified telescope operations. Of par- 
ticular interest is the possibility of placing a number of 
small telescopes on the moon (Genet et a/, 1992). Such a 
telescope facility would be an excellent test of our “sim- 
plified management structure”. We feel that ERE can 
provide a solid base for the development of integrated 
telescope planning, scheduling, and control systems that 
help to make this simplified management structure a re- 
ality. 
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The 0-Plan2 Project at the Artificial Intelligence Applications Institute of the University of 
Edinburgh is exploring a practical computer based environment to provide for specification, 
generation, interaction with, and execution of activity plans. 0-Plan2 is intended to be a 
domain-independent general planning and control framework with the ability to embed detailed 
knowledge of the domain. f f r- i f _, f \ ;/r v 


• A hierarchical planning system which can produce plans as partial orders on actions. 

• An agenda-based control architecture in which each control cycle can post pending tasks 
during plan generation. These pending tasks are then picked up from the agenda and 
processed by appropriate handlers ( Knowledge Sources ). 

• The notion of a “plan state” which is the data structure containing the emerging plan, 
the “flaws” remaining in it, and the information used in building the plan. 

• Constraint posting and least commitment on object variables. 

• Temporal and resource constraint handling. The algorithms for this are incremental 
versions of Operational Research methods. 


• 0-Plan2 is derived from the earlier Nonlin planner from which extended the ideas of Goal 
Structure, Question Answering and typed conditions. 

• We have extended Nonlin’s style of task description language Task Formalism (tf). 


i / 
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0-Plan2 could be applied to the following types of problems: 

• planning and control of space probes such as voyager, etc. 

• project management in large scale construction projects. 

• planning and control of supply logistics. 
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The Scenario 

• A user specifies a task that is to be performed through some suitable interface. We call 
this process job assignment. 

• A planner plans and (if requested) arranges to execute the plan to perform the task 
specified. 

• The execution system seeks to carry out the detailed tasks specified by the planner while 
working with a more detailed model of the execution environment. 



Figure 1: Communication between Central Planner and Ex. Agent 

We have deliberately simplified our consideration to three agents with these different roles and 
with possible differences of requirements for user availability, processing capacity and real-time 
reaction to clarify the research objectives in our work. 

A common representation is sought to include knowledge about the capabilities of the planner 
and execution agent, the requirements of the plan and the plan itself either with or without 
flaws (see Figure 1). 
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Figure 2: 0-Plan2 Architecture 
















Developer Interface 

0-Plan2 is implemented in Common Lisp on Unix Workstations with an X- Windows interface. 
It is designed to be able to exploit multi-processors in future and thus has a clear separation 
of the various components (as shown in Figure 2). Each of these may be run on a separate 
processor and multiple platforms may be provided to allow for parallelism in knowledge source 
processing. A sample screen image as seen by the 0-Plan2 developer or an interested technical 
user is shown in Figure 3. 



Figure 3: Example Developer Interface for the 0-Plan2 Planning Agent 
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User Interface 


AI planning systems are now being used in realistic applications by users who need to have 
a high level of graphical support to the planning operations they are being aided with. An 
interface to AutoCAD has been built to show the type of User Interface we envisage (see Figure 
4). The lower window draws the plan as a graph, and the upper right window can be useed for 
simulations of the state of the world at points in the plan. 



Figure 4: Example Output of the AutoCAD-based User Interface 
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Abstract 

This paper presents a new approach to rescheduling 
called constraint- based iterative repair. This approach 
gives our system the ability to satisfy domain con- 
straints, address optimization concerns, minimize per- 
turbation to the original schedule, and produce modi- 
fied schedules quickly. The system begins with an ini- 
tial, flawed schedule and then iteratively repairs con- 
straint violations until a conflict-free schedule is pro- 
duced. In an empirical demonstration, we vary the im- 
portance of minimizing perturbation and report how 
fast the system is able to resolve conflicts in a given 
time bound. These experiments were performed within 
the domain of Space Shuttle ground processing. 

Introduction 

Space Shuttle ground processing encompasses the in- 
spection, repair, and refurbishment of space shut- 
tles in preparation for launch. During processing the 
Kennedy Space Center (KSC) flow management team 
frequently modifies the schedule in order to accommo- 
date unanticipated events, such as lack of personnel 
availability, unexpected delays, and the need to re- 
pair newly discovered problems. If the Space Shut- 
tle ground processing turnaround time could be short- 
ened, even by a small percentage, millions of dollars 
would be saved. This paper presents GERRY, a gen- 
eral scheduling system being applied to the Space Shut- 
tle ground processing problem. 

As originally put forth in [Smi85], rescheduling sys- 
tems should satisfy domain constraints, address opti- 
mization concerns, minimize perturbation to the orig- 
inal schedule, and produce modified schedules quickly. 
GERRY [Zwe90] is a novel approach to rescheduling 
that addresses these concerns and gives the user the 
ability to individually modify each criteria’s relative 
importance. In an empirical demonstration of the sys- 
tem, we vary the importance of minimizing perturba- 
tion and report how fast the system is able to converge 
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to a conflict-free schedule (or a near -conflict-free sched- 
ule) in a given time bound. I ’ 

Problem Class: Fixed Preemptive 
Scheduling 

Scheduling is the process of assigning times and re- 
sources to the tasks of a plan. Scheduling assign- 
ments must satisfy a set of domain constraints. Gener- 
ally, these include temporal constraints, milestone con- 
straints, and resource requirements. The Space Shut- 
tle domain also requires the modeling of state vari- 
ables. State variables are conditions that can change 
over time; examples include the positions of switches, 
the configuration of mechanical parts, and the status 
of systems. Tasks might be constrained by the state 
conditions (a state requirement) and they might cause 
a change in state condition (a state effect). 

Preemption is an additional complicating factor in- 
troduced by the Space Shuttle problem. In preemptive 
scheduling, each task is associated with a calendar of 
legal work periods that determine when the task must 
be performed. 

Preemption effectively splits a task into a set of sub- 
tasks. Resource and state constraints are annotated 
as to whether they should be enforced for each indi- 
vidual subtask (and not during the suspended peri- 
ods between subtasks) or during the entire time span- 
ning from the first subtask until the last (including 
suspended periods). Preemptive scheduling requires 
additional computational overhead since for each task 
the preemption times must be computed and appropri- 
ate constraint manipulation for each time assignment 
must be performed. 

Rescheduling 

Rescheduling is necessitated by changes that occur in 
the environment. Systems can respond in three ways: 
schedule again from scratch, remove some tasks from 
the schedule and restart from an intermediate state, or 
repair the schedule where the changes occurred. 

Scheduling from scratch reconsiders the scheduling 
problem in light of exogenous events. In [Ham86], 
[Sim88] and [Kam90], the authors argue that it is 
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more efficient to modify flawed plans than to plan from 
scratch. Moreover, since scheduling from scratch will 
generate a new schedule without considering any values 
from the previous solution, a high amount of pertur- 
bation is likely to occur. 

To schedule from an intermediate state, all tasks af- 
fected by the exogenous events are first removed from 
the schedule; scheduling then is resumed considering 
the exogenous events. For example, suppose Ti, T2, T3, 
and T 4 are tasks in a schedule that are constrained to 
be sequential in the order shown. If T3 is delayed, then 
only T 3 and T 4 would be removed from the schedule be- 
fore restarting, because the other tasks are unaffected 
by the delay. This approach is complex, because a de- 
pendency analysis is required to determine whether a 
schedule modification could affect any particular task. 
Further, even though a task is unaffected by an ex- 
ogenous event, it may be possible to provide a better 
schedule by reconsidering its assignments. 

GERRY adopts the third approach, which is to re- 
pair the constraints that are violated in the schedule. 

Constraint-Based Iterative Repair 
Constraint-based iterative repair begins with a com- 
plete schedule of unacceptable quality and iteratively 
modifies it until its quality is found satisfactory. The 
quality of a schedule is measured by the cost function: 
Cost(s) = Ee, .Conjoin*. Penalty Ci (s) ♦ Weighty, 
which is a weighted sum of constraint violations. The 
penalty function of a constraint returns an integer re- 
flecting its degree of violation. The weight function of 
a constraint returns an integer representing the impor- 
tance or utility of a constraint. 

In GERRY, repairs are associated with constraints. 
Local repair heuristics that are likely to satisfy the vi- 
olated constraint can then be encoded without con- 
cern for how these repairs would interact with other 
constraints. Of course local repairs do occasionally 
yield globally undesirable states, but these states, if 
accepted (see below), are generally improved upon af- 
ter multiple iterations. 

Repairing any violation typically involves moving a 
set of tasks to different times: at least one task partici- 
pating in the constraint violation is moved, along with 
any other tasks whose temporal constraints would be 
violated by the move. In other words, all temporal 
constraints are preserved after the repair. We use the 
Waltz constraint propagation algorithm over time in- 
tervals [Wal75, Dav87] to carry this out (thus enforcing 
a form of arc-consistency [Mac77, Fre82]). The algo- 
rithm recursively enforces temporal constraints until 
there are no outstanding temporal violations. 1 This 
scheme can be computationally expensive, since mov- 
ing tasks involves checking resource constraints, calcu- 
lating preemption intervals, etc. 

! Note that all temporal constraints are also preserved 
(using the same Waltz algorithm) whenever the user man- 
ually moves tasks. 


At the end of each iteration, the system re-evaluates 
the cost function ‘to determine whether the new sched- 
ule resulting from the repairs is better than the current 
solution. If the new schedule is an improvement, it be- 
comes the current schedule for the next iteration; if it 
is also better than any previous solution, it is stored as 
the best solution so far. If it is not an improvement, 
with some probability it is either accepted anyway, or 
it is rejected and the changes are not kept. When the 
changes are not kept, it is hoped that repairs in the 
next iteration will select a different set of tasks to move 
and the cost function will improve. 

The system sometimes accepts a new solution that 
is worse than the current solution in order to es- 
cape local minima and cycles. This stochastic tech- 
nique is referred to as simulated annealing [Kir 83], 
The escape function for accepting inferior solutions 
is: Escape(s y s\T) = e -\Cost(t)-Co*t($')\/T w ^ ere 7 1 j 8 
a “temperature” parameter that is gradually reduced 
during the search process. When a random number be- 
tween 0 and 1 exceeds the value of the escape function, 
the system accepts the worse solution. Note that es- 
cape becomes less probable as the temperature is low- 
ered. 

In GERRY the types of constraints that can con- 
tribute to the cost function include the resource, state, 
and perturbation constraints. 

Resource Constraints The penalty of a resource 
capacity constraint is 1 if the resource is overallocated. 
If K simultaneous tasks overallocate the resource, then 
all K tasks are considered violated. One of these tasks 
will be selected in an attempt to repair as many of the 
K violations as possible. The heuristic used to select 
this task considers the following information: 

Fitness: Move the task whose resource requirement 
most closely matches the amount of overallocation. 
A task using a significantly smaller amount is not 
likely to have a large enough impact on the current 
violation being repaired. A task using a far greater 
amount is more likely to be in violation wherever it 
is moved. 

Temporal Dependents: Move the task with the 
fewest number of temporal dependents. A task with 
many dependents, if moved, is likely to cause tem- 
poral constraint violations and result in many task 
moves. 

Distance of Move: Move the task that does not 
need to be shifted significantly from its current time. 
A task that is moved a greater distance is more likely 
to cause other tasks to move as well, increasing per- 
turbation and potentially causing more constraint 
violations. 

For each of the tasks contributing to the violation, 
the system considers moving the task to its next ear- 
lier and next later times such that the resource is avail- 
able, rather than exploring many or all possible times. 
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This reduces the computational complexity of the re- 
pair and, like the “distance to move” criterion above, 
tends to minimize perturbation. 

Each candidate move is scored using a linear combi- 
nation of the fitness , temporal dependents , and distance 
to move heuristic values. The repair then chooses the 
move stochastically with respect to the scores calcu- 
lated. After the repair is performed, the Waltz algo- 
rithm moves other tasks in order to preserve temporal 
constraints. 

State Constraints The penalty of a state constraint 
is 1 if the required state is not set. To repair a state 
constraint, the task with the violated state requirement 
is reassigned to a different time when the state variable 
takes on the desired value. Similar to the resource ca- 
pacity constraints, the system considers only the next 
earlier and next later acceptable times and selects be- 
tween these randomly. We are currently investigating 
improvements to this repair and expect to extract more 
useful heuristics from our experts. One effort under- 
way is the development of a repair that can introduce 
new tasks into the schedule, thus yielding a behavior 
generally associated with AI planning systems. 

Perturbation Constraint The penalty function of 
the perturbation constraint returns the number of 
tasks that differ from their original temporal assign- 
ments. Since the weighted penalty of this constraint 
contributes to the cost of a solution, schedules with 
significant perturbation tend to be rejected at the close 
of an iteration. We are in the process of experimenting 
with repairs for this constraint that augment the in- 
formation provided by its penalty and weight. Below 
we show how varying the weight of this constraint can 
affect convergence speed and solution quality. 

Experiments 

The problem domain for the experiments consisted 
of the tasks, resources, temporal constraints, and 
resource constraints from the STS-43 Space Shuttle 
ground processing flow. A rescheduling problem was 
generated by taking the original conflict-free schedule 
and randomly moving ten tasks. Five such problems 
were generated for the results reported below. The first 
and last tasks of the original schedule were anchored 
in time so repairs could not extend the duration of the 
entire flow. 

In the experiments, we maintained the resource con- 
straint weight at ten, and varied the perturbation con- 
straint weight from zero (perturbation was of no con- 
cern) to 50 (perturbation was extremely important). 
The system terminated its search when all resource 
constraints were satisfied or when its run time exceeded 
ten minutes. Upon termination, the system returned 
the best solution found. Each rescheduling run was 
performed with the same settings 20 times in order to 
minimize stochastic variance. 

Figure 1 presents the results of our experiments on 


the five problems from three different perspectives. 
The first graph plots the number of perturbations for 
the returned solution against the weight of the pertur- 
bation constraint. As expected, with a higher pertur- 
bation weight, the best solution has fewer perturba- 
tions. 

The second plot shows the quality of a returned so- 
lution (measured as the number of violated resource 
constraints), as a function of the perturbation weight. 
As the graph shows, GERRY has more difficulty sat- 
isfying resource constraints as perturbation becomes 
more important. 

Finally, the third plot shows the convergence time 
(in cpu seconds) as a function of the perturbation 
weight. Average time to solution generally increased 
as the perturbation weight increased. 

It is interesting to note that for smaller weights on 
the perturbation constraint (< 20), the increase in re- 
source violations is small while the drop in number 
of perturbations is fairly large. As the perturbation 
weight increases beyond 20, resource violations rise 
quickly, and the drop in perturbations slows. 

In summary, our algorithm is interruptible, 
restartable, and outputs a solution when terminated. 
As demonstrated in Figure 2, the solution quality in- 
creases as a step-function of time. These runs are rep- 
resentative of the system’s general performance. 

Related Work 

Our work was heavily influenced by previous 
constraint-based scheduling [Fox87, Fox84, Sad89] and 
rescheduling efforts [Ow,88]. 

ISIS [Fox87] and GERRY both have metrics of con- 
straint violation (the penalty function in GERRY) 
and constraint importance (the weight function in 
GERRY). In contrast with our repair-based method, 
ISIS uses an incremental, beam search through a space 
of partial schedules and reschedules by restarting the 
beam search from an intermediate state. 

OPIS [Fox84, Ow,88], which is the successor of ISIS, 
opportunistically selects a rescheduling method. It 
chooses between the ISIS beam search, a resource- 
based dispatch method, or a repair-based approach. 
The dispatch method concentrates on a bottleneck re- 
source and assigns tasks to it according to the dis- 
patch rule. The repair method shifts tasks until they 
are conflict-free. These “greedy” assignments could 
yield globally poor schedules if used incorrectly. Con- 
sequently, OPIS only uses the dispatch rule when there 
is strong evidence of a bottleneck and only uses the re- 
pair method if the duration of the conflict is short. In 
contrast, GERRY uses the simulated annealing search 
to perform multiple iterations of repairs, possibly re- 
tracting “greedy” repairs when they yield prohibitive 
costs. 

Our use of simulated annealing was influenced by 
the experiments performed in [Joh90a, Joh90b]. In 
contrast with our constraint-based repair, their re- 
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Figure 1: Experimental Results: number of pertur- 
bations versus perturbation constraint weight; num- 
ber of resource violations versus perturbation con- 
straint weight; average run time versus perturbation 
constraint weight 


Figure 2: Best Cost versus Run Time 

pairs were generally uninformed. In [Zwe92b] we show 
that constraint repair knowledge improves convergence 
speed. 

The repair-based scheduling methods considered 
here are related to the repair- based methods that have 
been previously used in AI planning systems such as 
the “fixes” use_d in Hacker [Sus73] and, more recently, 
the repair strategies used in the GORDIUS [SimSS] 
generate-test-debug system, and the CHEF cased- 
based planner [Ham86]. 

In (Min90], it is shown that the min- conflicts heuris- 
tic is an extremely powerful repair-based method. For 
any violated constraint, the min- conflicts heuristic 
chooses the repair that minimizes the number of re- 
maining conflicts resulting from a one-step lookahead. 
However, in certain circumstances this lookahead could 
be computationally prohibitive. In [Zwe91], the au- 
thors investigate the tradeoff between the informed- 
ness of a repair and its computationally complexity. 
There it is shown that the resource repair described 
above outperformed a lookahead heuristic on the STS- 
43 Space Shuttle problem. However, on smaller prob- 
lems the lookahead heuristic was superior. 

Our technique is also closely related to the Jet 
Propulsion Laboratory’s OMP scheduling system 
[Bie91j. OMP uses procedurally encoded patches in 
an iterative improvement framework. It stores small 
snapshots of the scheduling process (called chronolo- 
gies) which allow it to escape cycles and local minima. 

[Mil88], [Bel85], and [Dru90] describe other efforts 
that deal with resource and deadline constraints. 

Conclusions and Future Work 

Our experiments suggest that our constraint frame- 
work and the knowledge encoded in this framework is 
an effective search tool that allows one to adjust the 
importance of schedule perturbation and other objec- 
tive criteria. The framework is modular and extensible 
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in that one can declare new constraints as long as their 
weight, penalty, and repair functions are provided. 

In future experiments, we hope to better character- 
ize the components of repair informedness and compu- 
tational complexity. We are currently evaluating can- 
didate metrics of problem difficulty that could be used 
to guide the selection of repair heuristics. Additionally, 
we are developing machine learning techniques that al- 
low systems to learn when to dynamically switch be- 
tween heuristics [Zwe92a]. 

With respect to the Space Shuttle application, the 
system is expected to be in daily use sometime this 
year. Our most significant barrier is gathering accurate 
models of tasks in an electronic form. We also plan to 
develop constraints that minimize weekend labor. 
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Abstract 

This paper describes an architecture for realizing 
the high quality production schedules. 

Although quality is one of the most important as- 
pects of production scheduling, it is difficult even for 
a user to specify precisely. However it is also true that 
the decision whether a schedule is good or bad can be 
taken only by a user. 

This paper proposes^ InS v X v \ 1 

*fhe quality of a schedule can be represented in 
the form of quality factors, i.e. constraints and 
objectives of the domain, and their structure^ 

factors and their structure can be used 
for decision making at local decision points during 
the scheduling process, --- 'A 

J 

* They can be defined via iteration of user specifi- 
cation processes. 

1 Introduction 

Production scheduling is a hard problem in general 
because of the large search space, large number of fac- 
tors lead to combinatorial explosion, and also its ill- 
structured (or ill-defined) nature. The primary con- 
cern of this paper is realizing high quality schedules, 
which is one of the major difficulties of production 
scheduling. 

Since the schedule should be evaluated by several 
often conflicting aspects, it is a common approach to 
expect the user to specify a single evaluation func- 
tion, i.e. satisfaction level of each aspect and priority 
among them.[6, 7, 13] However, it is difficult even for 
a user to define an evaluation criterion for a schedule 
precisely.fi] The methods that a system can use to de- 
cide an evaluation criterion, and to produce a schedule 


which optimizes that criterion, are important issues in 
this domain. 

Although it is difficult for users to define an evalu- 
ation criterion, at the same time, it is also true that 
the decision whether a schedule is good or bad can be 
taken only by a user. (Please compare other aspects, 
e.g. the performance of a system can be evaluated by 
an absolute measure - i.e. time. ) It follows that the 
schedule should be evaluated on domain specific infor- 
mation relating to a definition of quality given by the 
user. Furthermore, the quality information should be 
used for search guidance during scheduling, since the 
primary goal of search is affected by the decision of 
what a good/bad schedule is. 

Quality is determined by the combination of the 
extent to which constraints are satisfied and how well 
objectives are achieved. Since constraints and objec- 
tives can be regarded as atomic factors of the quality 
of a schedule, I call them quality factors in this paper. 

This paper describes an architecture which can ac- 
quire quality information from the user and reflect the 
information on the resulting schedule via iteration of 
user specification processes. This work is currently in 
progress. 

2 Analysis of quality factors 

2.1 Structure of quality factors 

Before attempting classification, this section will con- 
centrate on the relationships among quality factors. 

Since quality factors are defined by a user, they are 
often interrelated of each other. Some include other 
quality factors, and some cause another factor. For 
instance, a prohibition against changeover at the same 
time (due to a limitation on operators) can be divided 
into two levels below. 
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1. changeover itself - namely, a condition of 
changeover (defines this quality factor as QF1) 

2. simultaneous occurrence of QF1 (QF2) 

QF2 can be thought of as a meta-level quality factor. 

This information relating to the relationships 
among quality factors is quite useful for scheduling, 
and they are defined as a structure of quality factors 
in this paper. 

2.2 Classification of quality factors 

Quality factors can be classified from several points of 
views; for examples the function in areal plant[12, 14], 
the influence on scheduling.[3] In this section I at- 
tempt to classify quality factors based on the relat ion- 
ship with the scheduling algorithm. This classification 
is more detailed than others in order to use it for ac- 
quiring additional information about, quality factors 
from the user. 

hard — soft The first dimension of classification is 
based on the strictness of satisfaction /viol at ion ; 

• hard factor : one which must be satisfied, i.e. 
cannot be relaxed any more. 

♦ soft factor : one which is preferable to satisfy. As 
all quality factors are preferable to satisfy, soft 
factor can be defined as the complement of hard 
factor more strictly. 

Job and Resource The next dimension of classifi- 
cation is based on parameters which a factor contains. 
The parameters of a factor are either/both of Job and 
Resource, 

They can be broken down further according to the 
necessity for the reference to other objects during an 
evaluation of the quality factor as follows; 

Job - 

inter-lot need to refer to operations in other lots, 

intra-lot need to refer to other operations in the 
same lot and 

no- interaction ( no- int ) no need to refer to other op- 
erations, and 

Resource - 

inter-machine need to refer to other machine, 
intra-machine no need to refer to other machines. 


For instance, the parameters of a changeover(QF3) 
are Job and Resource and detailed class of Job part 
is inter-lot and that of Resource is intra-machine. 
Therefore, this quality factor, “a changeover” (QF3), 
can be classified as ( inter- lot Job , intra-machine Re- 
source) type. 

Global and local The last dimension is based on 
the applicability at a local decision point. Intuitively, 
global factors are those which can be used to evalu- 
ate a full schedule, while local factors are those which 
can be used to evaluate a partial schedule. However, 
many quality factors can be applied to the evalua- 
tion of candidates at a local decision point (even if 
it looks like global one) by using an estimation of re- 
sulting value. For instance, although QF2 in previous 
examples cannot necessarily always be applied at lo- 
cal decision points as it is, it might be possible if the 
probability of changeover for each product type could 
be estimated. 

It follows that the revised version of the definition 
is 

A global factor is one for which a user cannot define 
an estimation function at all. 

A local factor is the complement of global factor, 
i.e. those which a user can define so that they 
can be applied at local decision points. 

3 Scheduling via quality 
factors 

3.1 Iterative user specification pro- 
cesses 

In the previous section, the concept of quality factors 
was introduced. This concept makes it possible to 
characterize the user's evaluation of a schedule, men- 
tioned earlier , as follows. 

Suppose as an example two schedules are compared, 

1. apply hard quality factors to every item - pre- 
sumably operations - of each schedule. 

IF violation has occurred in either of two sched- 
ules — * unacceptable schedule 

ELSE — ► next step 

2. apply most important soft quality factors to 

- every item of the schedule - if the quality factor 
is local 

- the whole schedule - if the quality factor is 
global 
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IF a sufficient difference between them is identi- 
fied in any of the quality factors — * decide 

ELSE — * next step 

3. apply next level of soft-quality factors 
... same as above. 

If the importance of every QF could be categorized 
and exact values for a sufficient difference could be 
defined beforehand, this process could be done auto- 
matically and it might be possible (apart from realis- 
tic processing speed) to optimize a schedule. However, 
specification - especially the criterion for sufficiency - 
is difficult (or close to impossible) to define precisely 
in advance. Consequently, it will be indispensable to 
adopt some sort of trial and error process for deciding 
a good schedule. From this view, the following pro- 
cedure should be an acceptable method for acquiring 
the information from a user. 

1. user specifies each quality factor 

user specifies priority among quality factors in as 
much detail as possible. 

2. system produces a schedule based on quality in- 
formation acquired so far. 

3. user analyzes the resulting schedule produced in 
the previous step. 

user judges whether the schedule is satisfactory 
or not. 

IF satisfactory — ► end. 

ELSE — ► specify which QF should be im- 
proved. 

4. system re-structures quality information 
goto 2. 

3.2 Search guidance by quality factors 

..]^. : >! , 

Schedule production, i.e. step 2 in the procedure de- 
fined in the previous section, is accomplished by a 
repetition of target selection , i.e. operation, and a 
reservation for it, i.e. resource and start time. In the 
each repetition cycle, it is desired to rate candidates 
appropriately which results in a good overall schedule. 
The next section focuses on this rating step. 

3.2.1 Rating by quality factors 

When a schedule can be evaluated by a function - 
defines it as E - two dimensions can be viewed as 
rating methods. 


local optimization(LO) how good will the quality 
of a partial schedule be 

— measures candidates by E(Pn) : where Pn is 
a partial schedule after adopting candidate-N 

predicted global optimization(PGO) how good 
is the quality of the final schedule likely to be, in 
other words from the opposite perspective, how 
difficult will expected problems be. 1 

— measures candidates by E'iPn) : where E f is 
a probabilistic function which expresses the value 
likely to be achieved. 

As described in section 3.1 , E is realized by a series of 
applications of quality factors and filtering out in each 
quality factor application. E f is similar in general, 
since a predicted final schedule should be evaluated 
in the same manner. However a probability among 
quality factors should be also taken into account as 
well as the priority among them. For instance, if it is 
is known that QF1 frequently identifies a bad value, 
it might be better to apply QF1 prior to other QFs, 
even though the priority of QF1 is not highest. 

The application of quality factors is stopped when 
a sufficient difference among candidates is identified. 
This difference is described as a threshold in this pa- 
per. 

3.3 Feedback from the result 

In this section, we describe how the system re- 
structures quality factors in reaction to the schedule 
produced, i.e. step 4 in the procedure defined in Sec- 
tion 3.1. This process can be accomplished both au- 
tomatically and manually. 

3.3.1 Manual feedback 

As described earlier, the user should judge whether 
the resulting schedule is satisfactory or not. Generally 
speaking, a user can communicate with the system 
via quality factors and structures among them. That 
is, if the schedule is not satisfactory for a user, the 
reason why its schedule is not satisfactory is expressed 
by indicating which quality factors’ values should be 
improved. This feedback from the user will influence 
structures of quality factors. 

In order to support a user in detecting problems, 
the system provides information, as follows: 

verification of assumption It is unrealistic to ex- 
pect that a user can specify the structure of 

1 There are two heuristics for realizing this method; i.e. vari- 
able ordering and value ordering. [5] 
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quality factors precisely from the early stages of 
scheduling generation. Consequently, a system 
should assume some information about structure. 
The information assumed by a system should be 
verified at the end of scheduling generation pro- 
cess by the user. The user is informed of assumed 
structures at the feedback stage. 

evaluation by global factors Resulting schedules 
can often be evaluated at a gross level by global 
factors, like overall utilization, although all qual- 
ity factors should be involved for a precise evalu- 
ation. Furthermore, since global factors are con- 
sidered only via causal factors during the schedul- 
ing generation process, verification is indispens- 
able. Statistical information based on global fac- 
tors is provided by the system automatically. 

evaluation by specific factors It is quite usual 
that a user knows which quality factor is criti- 
cal in the specific application/domain. Statisti- 
cal information is also provided in response to the 
user. 

3.3.2 Automatic feedback 

When scheduling has not been completed, i.e. there 
remain unassigned operations, the system analyzes its 
reasons and restructures quality information based on 
some heuristics, which include 

• If there are quality factors in which unassigned 
operation got the best value 

— *• decrease threshold of those quality factors 

• If there are quality factors in which unassigned 
operation was the next candidate 

— ♦ increase threshold of those quality factors 

4 System structure 

The system consists of mainly four parts, namely; 
Scheduler, Generator, Analyzer and Data-Base man- 
ager and 

six system files, namely; Quality Data Base(QDB), 
Evaluation Procedures File(EPF), Scheduling results 
File(SF), Decision history file(DHF), Order file(OF) 
and Knowledge-Base(KB). 

The general flow of this system is as follows (this 
can be thought of as a detailed version of the iterative 
procedure described in Section 3.1.); 

1. user specifies initial information 

• order data (presumably from other system) 
OF 


• domain information, e.g. factory, machine 
— ► KB 

• quality factor 2 — * KB 

• attribute of quality factors, e.g. global/local 
, hard/soft — ► QDB 

• structure of quality factors (in as much de- 
tail as possible) — * QDB 

2. Generator generates evaluation 

procedures, which can be used in the rating of 
candidates during scheduling process, based on 
QDB information and output — ► EPF 

3. Scheduler generates a schedule based on OF, KB 
and EPF and output 

• resulting schedulefincluding unassigned op- 
erations) — ► SF 

• history of rating by quality factors at every 

local decision points DHF 

4. Analyzer analyzes SF and DHF and queries the 
user if necessary and restructures QDB. 

goto 2 if not satisfactory 

5 Future work 

This system uses a traditional algorithm as its 
scheduling mechanism, since the scheduling algorithm 
itself is not the major concern. However, it is obvious 
from the analysis in Section 3.2 that quality infor- 
mation which is acquired from a user and scheduling 
algorithm have tight connection. It follows that the 
ideas proposed here are restricted by this algorithm. 
It is required to analyze validity on other algorithms, 
e.g. distributed scheduling system[4] , as well and ex- 
tend these ideas. 

This system is now being implemented and will be 
evaluated using real problems, although it is based 
on my experiences in developing practical production 
scheduling systems. [9, 8] 

6 Conclusion 

Although quality is one of the most important parts 
of production scheduling, it is difficult even for users 
to define precisely. The first step in realizing a high 
quality production schedule is to clarify what “high 
quality” means. 

2 The system requires a user to specify function which rep- 
resents the goodness of the selected candidate for every qual- 
ity factor. At the same time, the current system also requires 
a probabilistic function for each quality factor, although this 
should be eventually supported by the system. 
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This paper proposed; 

• The quality of. production schedules can ulti- 
mately be evaluated/measured only by a user, 
and his intention can be represented in the form 
of quality factors and their structures defined by 
him/her. (global evaluation) 

• Quality factors and their structures can be used 
for decision making at local decision points during 
the scheduling process, (local evaluation) 

• They can be refined via iteration of the user spec- 
ification process, (iterative process) 
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Abstract 

The cost of building new semiconductor wafer fabrica- 
tion factories has grown rapidly, and a state-of-the-art 
fab may cost $250 million or more. Obtaining an ac- 
ceptable return on this investment requires high pro- 
ductivity from the fabrication facilities. 

This paper describes the Photo Dispatcher system 
which has been developed to make machine-loading 
recommendations at a set of key fab machines. Dis- 
patching policies that generally perform well in job 
shops (e.g., Shortest Remaining Processing Time) per- 
form poorly for workstations such as photolithography 
which are visited multiple times by the same lot of 
silicon wafers. 

The Photo Dispatcher evaluates the history of work- 
loads throughout the fab and identifies bottleneck ar- 
eas. The scheduler then assigns priorities to lots de- 
pending on where they are headed after photolithog- 
raphy. These priorities are designed to avoid starving 
bottleneck workstations and to give preference to lots 
that are headed to areas where they can be processed 
with minimal waiting. Other factors considered by the 
scheduler to establish priorities are the nearness of a 
lot to the end of its process flow and the time that the 
lot has already been waiting in queue. 

Simulations that model the equipment and prod- 
ucts in one of Texas Instruments^ wafer fabs show the 
Photo Dispatcher can produce a 10% improvement in 
the time required to fabricate integrated circuits. 

Introduction 

Texas Instruments has a number of integrated-circuit 
(IC) wafer fabs which produce many different chip 
types. Depending on the type of chip on a wafer, fabri- 
cating that wafer will place very different demands on 
the processing equipment. Planning systems are used 
to produce weekly wafer start-plans that are within the 
capacity of the fab equipment. These planning systems 
do not develop a schedule for when each wafer will visit 
each machine group; instead they try to ensure that no 
more than a week’s worth of work is started for all ma- 
chine groups. 


While good start plans have helped avoid some of the 
problems of machine overloading and late orders, these 
problems have not totally disappeared in the wafer 
fabs. Machine breakdowns, rework, etc., make it in- 
evitable that production rarely proceeds as smoothly 
as desired. The manufacturing staff reacts to these 
disruptions by reprioritizing lots of wafers to expedite 
l ots th at are behind schedule or ^o cure workload im- 
balances on equipment. We developed the Photo Dis- 
patcher to investigate the possibility of automating the 
scheduling of a set of key machines in the photolithog- 
raphy area. • 

The photolithography area was chosen because lots 
continually revisit this area during their processing, 
so improved scheduling in t his area shou ld have wide- 
reaching impact on the wafer fab. Figure I shows a 
typical process flow for producing a bipolar device with 
seven pattern steps. As shown in the figure, all of 
the pattern steps are performed on the same set of 
projection printers, Printers Grp. A scheduler for the 
Printers Grp would impact this device seven times as 
opposed to a scheduler for Depos Grp 6 which would 
would impact this device only once. 

Previous Research 

One approach to scheduling the Printers Grp would 
be to generate a Gantt chart each shift that shows 
which lots should be processed on which projection 
printers at which times. We decided not to take this 
approach because we felt that these schedules would 
quickly become obsolete because of projection printer 
breakdowns, unpredictable lot arrivals, and the unpre- 
dictable need to rework lots whose first patterning was 
unsatisfactory. This approach might also be difficult to 
scale up to schedule all the machine groups in the wafer 
fab because of the large number of machines (400+) 
and lots in process (400+). 

An alternative is to wait until it is time to load a free 
machine and then decide which lot to load based on 
what is in queue and current fab conditions. Dispatch 
policies, which have been studied extensively in Op- 
erations Research (e.g., Panwalker it Iskander, 1977), 
are one way to make this decision. First-in-First-Out 
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Process Step Step Typs Equipment 

First Oxidation Layer Furnace Grp 10 


E)UF Pattern 
DUF Diffusion 
Epitaxial Deposition 
Second Oxidation 
Isolation Pattern 
isolation Diffusion 
Base Pattern 
Base Dillusion 
Emitter Pattern 
Emitter Dillusion 
Contact Pattern 
Aluminum Evaporation 
Metal Pattern 
Deposit Overcoat 
Bonding Pad Pattern 
Electrical Test 


Pattern Printers Grp 
Dope Furnace Grp 20 
Layer Epi Reactors 
Layer Furnace Grp 10 
Pattern Printers Grp 
Dope Furnace Grp 32 

Pattern Printers Grp 
Dope Furnace Grp 53 

Pattern Printers Grp 
Dope Furnace Grp 60 

Pattern Printers Grp 
Layer Alum Evap Grp 
Pattern Printers Grp 
Layer Depos Grp 6 

Pattern Printers Grp 
Test Tester Grp 


Figure 1: All of the pattern steps are performed in the 
photolithography area of the fab on the same equip- 
ment, Printers Grp. Wafers fabricated using the pro- 
cess flow iUustrated make seven visits to Printers Grp. 

(FIFO) is an example of a simple dispatch policy. 

However, for the current application, dispatch poli- 
cies have the following drawbacks: 

1. Many dispatch policies do not work well on revisited 
machine groups like Printers Grp. 

2. The typical dispatch policy is myopic in the sense 
that it considers only the local situation and does not 
consider the needs of downstream machine groups. 

A dispatch policy such as Shortest Remaining Pro- 
cess Time (SRPT) will lead to problems when applied 
to a revisited workstation like the Printers Grp. If the 
queue for Printers Grp is made up of a number of lots 
with the process flow shown in Figure 1, then SRPT 
will prefer lots that are at their last pattern step, Bond- 
ing Pad Pattern. It will only select lots at the first 
pattern step, DUF Pattern, if there are no other lots 
in the queue. This leads to long waiting times at DUF 
Pattern and alternating starve/glut feeding patterns 
for DUF Diffusion. 

We have investigated other dispatch policies such as 
Shortest Processing Time and Slack to Due-Date, but 
our experience has been that they also share the defect 
of SRPT of being biased in favor of one or another of 
the pattern steps and neglecting others. The problem 
seems to be that these policies are “winner take all” 
policies as opposed to “winner take a bigger share” 
policies. There is nothing wrong with adding priority 
to lots near the end of their flows or lots in trouble with 


their due dates. What causes problems is that “winner 
take all” schemes based on these factors run the risk 
that low priority lots may wait forever if higher priority 
lots arrive fast enough. To get around this problem, 
the Photo Dispatcher uses a variation of a round-robin 
scheme which provides a “winner take a bigger share” 
selection. 

The FIFO dispatch policy is not biased in favor of 
particular pattern steps, but it is myopic in the sense 
that it will select lots that will just have to sit at their 
next process step because a key machine is down. Al- 
ternatively, it may pass over lots that would help keep a 
downstream bottleneck machine group from starving. 
Goldratt’s OPT system (1984, 1988) emphasised the 
importance of bottleneck resources in scheduling. AI 
scheduling systems that emphasize the importance of 
bottleneck resources include Smith, Fox, k Ow (1986) 
and Eskey k Zweben (1990). The Photo Dispatcher 
avoids myopic decision making by monitoring current 
curd historical workloads throughout the wafer fab and 
reacting to these workloads to avoid starving bottle- 
neck workstations and avoid sending lots to worksta- 
tions where they will just sit in queue. 

Approach 

The Photo Dispatcher makes recommendations about 
which lot of wafers in the queue should be processed 
next by Printers Grp. The Photo Dispatcher develops 
these recommendations in three stages: 

1. Establish priorities for processing lots at the differ- 
ent pattern steps. 

2. Use the priorities to choose a pattern step to work on 
next. That is, decide whether to work on a lot that 
is waiting for DUF Pattern, or Isolation Pattern, etc. 

3. Choose a specific lot wcu ting for that pattern step. 
There are typically several lots waiting for DUF Pat- 
tern and this third stage determines which of these 
lots should be recommended. While a number of 
different criteria have been investigated for making 
this lot selection, none of them have outperformed 
FIFO, so currently this selection is just based on 
time of arrival of the lots waiting for DUF Pattern. 

Pattern-Step Priorities 

Figure 2 gives an example of the calculation of priori- 
ties for four pattern steps. Three numbers are summed 
to determine priorities. The percentage of lots waiting 
for a particular pattern step (e.g., 20 percent for DUF 
Pattern) is added to a number that is based on the 
nearness of that pattern step to the end of the pro- 
cessing flow (e.g., 01, the first two digits of the step id 
number). Finally, a positive number (e.g., 30) is added 
if more work is needed at downstream work areas or 
a negative number is added if there is too much work. 
The higher the priority number for a pattern step the 
more lots at this step will be recommended for pro- 
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0100 DUF PATTERI 


X Lots Queued 

20 


Flow Position 

01 


Feedback 

30 

(Send More; 


— 

Short Wait at 

Priority 

51 

Furnace Grp 20) 

0600 ISOLATION PATTERI 

% Lots Queued 

04 


Flow Position 

06 


Feedback 

-30 

(Send Less; 


— 

Long Vait at 

Priority 

-20 

Furnace Grp 32) 

2300 BASE PATTERI 


X Lots Queued 

12 


Flow Position 

23 


Feedback 

00 

(lo Adjustment; 


— 

Average Wait at 

Priority 

35 

Furnace Grp 53) 

6000 corner : 

PATTERI 

X Lots Queued 

05 


Flow Position 

60 


Feedback 

60 

(Send Much More; 


— 

Starving Bottleneck 

Priority 

125 

Alum Evap Grp) 


Figure 2: Three factors determine the priority of a par- 
ticular pattern step: the fraction of lots waiting for this 
pattern step, the nearness of this pattern step to the 
end of the process flow, and feedback from downstream 
work areas. 


cessing. The rationale for each of the three factors 
illustrated in Figure 2 will be discussed in turn. 

% Lots Queued If the process flow in Figure 1 was 
used by all devices, there would be roughly equal num- 
bers of lots waiting for the individual pattern steps. 
However, since there are roughly 300 different process 
flows, the pattern steps do not occur with equal fre- 
quency. Including a factor for the percentage of lots 
waiting for a particular pattern step ensures that the 
round-robin scheme does not penalise lots that are 
waiting for frequently used pattern steps. 

Flow Position The second factor, nearness of a 
pattern step to the end of the process flow, has the 
effect of reducing work-in-process (WIP). Lou and 
Kager (1989) recommend that when scheduling re- 
visited workstations in IC fabrication, higher priority 
should be given to process steps that are later in the 
process flow. Our experiments confirm the benefits of 
this practice. 

Feedback From Downstream Workstations 
The feedback to Contact Pattern in Figure 2 shows 
a bottleneck, Alum Evap Grp, requesting additional 
work because it is starving. Figure 3 illustrates the 
computations performed to determine this machine 
group is a starving bottleneck. A software object called 
a Work Monitor is associated with machine groups in 
the fab. WORK-FOR-ALUM-EVAP knows how to use 
the current position of a lot provided by the WIP track- 
ing system to determine whether that lot is at a process 
step that uses the Aluminum Evaporators. In the case 
illustrated in Figure 3, there is one lot consisting of 
48 wafers arrived at a processing step using the Alu- 
minum Evaporators. WORK-FOR-ALUM-EVAP also 
can tell if a lot has left photolithography and is on the 
way to a process step using the Aluminum Evapora- 
tors but has not arrived yet. Identifying lots that have 
been sent to the Alum Evap Grp provides an estimate 
of upcoming workloads. 

WORK-FOR-ALUM-EVAP knows how to translate 
the number of wafers arrived into Jhe time it should 
take the AlumlSvap Grp to complete processing those 
wafers. In Figure 3 the 48 wafers arrived are estimated 
to keep the Aluminum Evaporators busy for the next 
.58 his. The following factors are considered to deter- 
mine how many hours it will take to complete process- 
ing a particular set of wafers: 

1. number of machines in Alum Evap Grp and their 
capacities 

2. process time for each wafer; different devices may 
have different processing times 

3. setup times 

Work Monitors categorize workloads along four 
different dimensions (TYPICAL-LOAD, COMPARE- 
NOW-TO-HISTORY, etc.) and these dimensions are 
referenced by rules that determine the appropriate 
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VORK-FOR-ALUM-EVAP 

Lots sent to Hub Evap Grp: 0 lots, 0 wafers 

Lots arrived at Alum Evap Grp: 

1 lot, 48 wafers 

Est work in queue for Alum Evap Grp: 

14 wafers, 0.26 hrs 

Est work in process for Alua Evap Grp: 

34 wafers, 0.32 hrs 

Estimated work available « .58 hrs 

The avg amount of work, 10.43 hrs, that 
arrives in this area is HIGH relative to the 
long-run avg (4.44 hrs, sigma=3.19) 
for all areas. 

Work currently arrived in this area, .58 hrs, 
is LOV relative to the long-run avg 
(10.43 hrs, sigma-6.28) for this area. 

Work currently arrived in this area, .58 hrs, 
is LOV relative to the avg currently arrived 
(3.51 hrs, sigma s 3.66) for all areas. 

Work currently sent to this area, 0.00 hrs, 
is LOV relative to the long-run avg 
(2.70 hrs, sigma = 0.64) for this area. 

The classification is: 

TYPICAL-LOAD HIGH 

CGMPARE-I0V-T0-HIST0RY LOV 
C0HPARE-T0-GTHER-HACHS LOV 
COMP ARE-SEIT-T0-HI STORY LOV , 

so MUCH MORE work is needed. 


Figure 3: An example of a starving bottleneck. The 
Aluminum Evaporators typically have 10.43 hrs of 
work; however, at the time this workload evaluation 
was performed there was only .58 hrs of work and none 
on the way. A request for much more work is fed back 
to Contact Pattern. 


feedback (e.g., send MUCH MORE). By changing the 
feedback rules, a wide variety of workload regulation 
schemes can be implemented. Simulation experiments 
w«erun to evaluate three different workload regula- 
tion schemes: Bottleneck Starvation Avoidance, Small- 
est Nex t Queue, and Workload Smoothing. Each of 
these three workload regulation schemes performed 
well at some WIP levels, but none of the three was su- 
perior at all WIP levels. A hybrid of these approaches 
was devised which performed well at all WIP levels 
investigated. 

Some approaches to scheduling using bottleneck 
starvation avoidance require that the there is only one 
bottleneck and its identity is known in advance and 
provided as input to the scheduler (e.g., Glassey k Re- 
Bende 1988). This assumption makes it difficult to han- 
dle shifting bottlenecks which can arise in wafer fabs 
because of a change in product mix or the breakdown 
of key equipment. The work-monitoring mechanism of 
the Photo Dispatcher determines which workstations 
are bottlenecks by gathering workload histories. As 
the bottlenecks change over time the shift in workload 
histories is tracked by the Work Monitors and the pri- 
ority of lots is changed accordingly. 

Using Priorities to Select a Pattern Step 

Priorities are recomputed periodically based on the 
current workloads at downstream machine groups and 
the number of lots queued for each pattern step. 
The priorities influence subsequent selection of pattern 
steps by controlling a round-robin scheme. 

Each time a machine in Printers Grp is ready to be 
loaded, the round-robin advances to the next pattern 
step in the cycle. The priority assigned to this pat- 
tern step determines whether a lot is chosen from this 
pattern step or whether the round-robin immediately 
advances to the next pattern step. Priority numbers 
are rescaled to range from 5 to 100 and pattern steps 
with priority 5 have a lot selected one out of every 20 
times the round-robin stops there (5%), pattern steps 
with priority 50 have a lot selected every other time 
^heround- robin stops there, etc. 

When the priorities are as shown in Figure 2, a 
sequence of selections produced by this round- robin 
might be Contact Pattern, DUF Pattern, Base Pat- 
tern, Contact Pattern, Contact Pattern, DUF Pattern, 
Contact Pattern, .... By interleaving pattern steps in 
this fashion there is limit on how many times a low 
priority pattern step can be passed over before it is 
selected. 


Results 

The Photo Dispatcher was tested using a simulation 
of one of Texas Instruments’ wafer fabs. The fab in 
question manufactures a wide variety of Bipolar and 
BiMOS devices. The simulation modeled all of the 103 
machine groups (410 machines) in the fab and all of the 
process steps needed to fabricate any of the roughly 
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FIFO 


m&m 

Output 

K*M 



339 

140 

328 

140 

400 

482 

132 

427 

136 

675 

680 

138 

Minim 

141 

1000 

1068 

132 

975 

136 


Table 1: In simulation experiments, the Photo Dis- 
patcher produces an improvement over a FIFO policy 
in the average number of hours needed to complete 
processing a lot of wafers (i.e., cycle time or CT). The 
same lot starts were used in all simulations, so WIP 
levels were manipulated by varying the number of ini- 
tial WIP lots in the fab at the start of simulation. 

300 different ICs produced. There are roughly 50 pro- 
cess steps in the recipe for a typical IC in this fab and 
these process steps are broken down in the simulation 
to 165 separate operations each of which requires the 
use of another machine. The simulation included ran- 
dom machine breakdowns, but this was the only ran- 
dom component as processing times were assumed de- 
terministic, lot transport time was not modelled, and 
there were no operator limitations. 

Table 1 shows the Photo Dispatcher has better aver- 
age cycle- time performance in simulations than a FIFO 
policy. FIFO does not separate the decision of which 
lot to process next on Printers Grp into a pattern step 
selection followed by a lot selection. Instead it merely 
finds the lot that has been waiting longest for the print- 
ers and starts that lot. This is the default behavior of 
the simulator and it is also used when exercising the 
Photo Dispatcher for machine groups other than the 
Printers Grp. 

The sise of the cycle-time improvement depends on 
the amount of WIP in the simulated fab. At WIP levels 
above 400 lots, the Photo Dispatcher reduced cycle- 
times by roughly 10% with greater output in terms 
of finished lots per week. Since the fab being simu- 
lated currently operates at WIP levels in excess of 400 
lots, a 10% cycle-time improvement was projected from 
the use of this scheduler. Results to date suggest that 
flow position is the most important factor in producing 
cycle-time improvements of the three factors combined 
in Figure 2. 


ing of fab operations. However, its Work Monitor ca- 
pability has been used to a limited degree to analyse 
production problems in fabs. 
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Summary 

The Photo Dispatcher provides an effective schedul- 
ing approach for revisited workstations such as pho- 
tolithography in IC fabrication. It takes advantage of 
the unique opportunity that these revisited worksta- 
tions provide to shift workloads from one downstream 
area to another and to reduce WIP by speeding up 
processing on lots near the end of their process flows. 

While the Photo Disptacher was developed with the 
intention of installing it in Texas Instruments 9 wafer 
fabs, to date it has not been used for real-time schedul- 
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Abstract 

This article describes a planning method 
applicable to agents with great perception and 
decision-making capabilities and the ability to 
communicate with other agents. Each agent has 
a task to fulfil allowing for the actions of other 
agents in its vicinity. Certain simultaneous 
actions may cause conflicts because they 
require die same resource. The agent plans each 
of its actions and simultaneously transmits 
these to its neighbours. In a similar way, it 
receives plans from the other agents and must 
take account of these plans. The planning 
method allows us to build a distributed 
scheduling system. 

Here, these agents are robot vehicles on a 
highway communicating by radio. In this 
environment, conflicts between agents concern 
the allocation of space in time and arc 
connected with die inertia of die vehicles. Each 
vehicle make a temporal, spatial and situated 
reasoning in order to drive without collision. 

The flexibility and reactivity of the method 
presented here allows the agent to generate its 
plan based on assumptions concerning the 
other agents and then check these assumption 
progressively as plans are received from the 
other agents. A Multi-agent execution 
monitoring of these plans can be done, using 
data generated during planning and the multi- 
agent decision-making algorithm described 
here. A selective backtrack allows us to 
perform incremental rescheduling. 

Keywords 

Anytime Planning and Scheduling Algorithms, 
Execution Monitoring and Incremental 
Rescheduling, Managing limited computation 
time. Dependency Analysis and Plan Reuse, 
Autonomous Agents. 

1 Multi-agent worlds 

Monitoring a little structured multi-agent 

environment, such as a highway traffic, is an 

extension to the problem of monitoring robots 

in a factory. The agents are assumed to be 
“high-level” since they must have a great ability 
to perception and they must communicate with 


each other to cooperate, coordinate their actions 
and resolve any conflicts. The resolution of 
conflicts is the main point of interest. Logic 
schemata, attempting to model human thinking, 
have been developed to represent the wishes 
and beliefs [Bessierc, 84] [Wilks and Ballim, 
87] which are the mutual basic knowledge 
needed to resolve conflicts. Persuasion 
[Rosenschein, 82][Sycara, 89] is the aim of 
exchanging arguments. Most studies are 
simplified by assuming that agents cooperate 
(see [Cammarata et al., 83]). Rosenschein and 
Genesercth [Rosenschein and Genesercth, 85], 
on the contrary, attempt to allow for agents 
which arc not necessary “benevolent”. 

2 The motorway 

Unlike Wood [Wood, 83], we do not generate 
routes but consider the driving of the vehicle 
(acceleration, lane changes, etc.). We shall use 
a different approach to Fraichard and Demazeau 
[Fraichard and Demazeau, 89], who describe a 
centralized system to generate vehicle 
trajectories at cross-roads. We use a distributed 
system in which the number of central units 
increases as the number of agents increases. 
The multi-agent world was modelled on this 
basis (see [Mourou and Fade, 91a] and 
[Mourou, 90]). 

Each vehicle has a co-pilot computer which 
may either be in an automatic mode, driving the 
vehicle, or in a supervision mode when it 
warms the driver or, if necessary, takes over 
control when an accident is imminent 

When all vehicles are in the "automatic 
driving" mode, it is simple: the vehicles are 
considered as autonomous robots which 
communicate with each other. Die supervision 
mode requires a veritable “execution 
monitoring 1 * * * 5 ’ which must be highly flexible and 
supervise drivers' acts by comparing them with 
the “ideal” plan generated in the automatic 
mode. 

Co-pilots exchange data via a short-range 
communication network. The agents must 
cooperate to guarantee “efficient and safe traffic 
movement” and must respect the highway 
code, used as veritable “cooperative strategy” 
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[Cam m a rata et al., 83]. A number of objectives 
are also fixed for each agent, such as "to travel 
at the mean speed required by the driver”. 
Unlike certain systems analyzed by Davis and 
Smith [Davis and Smith, 83], no tasks need be 
shared in the procedure since each agent knows 
what he must do. The negotiation therefore 
covers solely how its tasks can be 
accomplished. 

The co-pilot in each vehicle is concerned 
solely by the N relations which affect the 
vehicle. The task of the co-pilot will therefore 
involve selecting the behaviour, which is 
satisfactory to the N influences to which it is 
exposed at each time. In considering highway 
traffic, the "common resource" is the space 
available on the road. The main task of each 
agent is to check that the space it needs will be 
free and, if not, to take appropriate action to 
reach a free space (acceleration, lane changes, 
etc.). Conventional problem resolution 
techniques are not capable of simultaneously 
managing the N conflicts possible at each 
instant in the future. Moreover, a "distributed 
scheduling" technique will be unsuitable since, 
although automatic control can be considered as 
a resource allocation problem, the inertia of the 
various vehicles will make it extremely difficult 
to break die road down into a series of "areas", 
each considered as a resource. 

The method we describe is more "expert"- 
oriented, allowing the "rules" in the highway 
code to be expressed and used as they exist and 
high-level data exchanges to be used. For 
example "I'm going to move out and accelerate 
up to 1 10 km/h" is a kind of action generated 
by the planner and broadcasted through the 
network. 

3 Time, influence of other plans and 
delay 

The behaviour of each agent is represented by a 
linear, non-hierarchical plan. We malra the 
assumption that the agents are synchronised by 
a common clock broadcast by radio for 
example. B’s “time influence” on A covers all 
the B’s actions and situations around Tj used to 
plan A's action at Tj. When some of them are 
missing, A must make assumptions on the 
actions planned by B and consequently 
progressively check these assumptions as the 
actual actions are received. If A's assumption is 
found to be correct, we shall have saved time. 
Otherwise, A must replan this action after B 
has transmitted its decision and no time will 
have been lost 

4 The “Is there an agent... ?” method 
Knowing, or assuming, the actions of other 
agents, agent A must generate an action (the 
behaviour for a given step). It can repeatedly 


pose this kind of question : “Is there an agent 
preventing me doing this ?”. Each question 
determine whether there is a conflict which 
prevents one action (method Ml). 

An example of situation (Example I) : 


to® > 



can be given by the possible conflicts A will 
detect: 

(Cb) : B is in front of A (Us), which is 
travelling faster and wants to accelerate 
even further. 

(Cc) : C is on the left of A and prevents A 
overtaking. 

Questions which A could ask before 
deciding to “slow down” are: 

• Can I accelerate ? (agent B imposes the 

reply “no”) 

• Can I move out to overtake B ? (agent C 

imposes the reply “no”). 

At a first view, it could be difficult to write 
directly an algorithm capable of taking a 
decision ada p ted to A’s wishes when exposed 
to complex influences (see Figure 1). 



Figure 1. Method Ml 


5 The dual method: “Is there an 
action... ?” 

5.1 Definition 

We could use tests of the type “Is there an 
action prevented by this agent ?”. The agents 
would then be reviewed, one after the other, to 
collect all conflicts to which A is exposed into a 
“Results” structure (see Figure 2). 
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• "Is there an action prevented by B ?” : 

“B prevents me not(slowing down or 

moving out)" = Q, 

• "Is there an action prevented by C ?” : 

“C prevents me moving out” = Q 

A second phase allows the action to be 
determined : 

• Cb and C c -*> “prevented from not 

slowing down” = “decelerate” 

TTiis second phase, used to find the best 
possible response in view of all the behaviours 
that are prevented and the requirements of A, 
occurs after determining all behaviours that are 
not possible (method M2). It allows K conflicts 
to be grouped and assessed simultaneously (K 
< P: maximum number of conflicts). It could 
be considered as simplified multi-agent 
planning which chooses an action in function 
of the prevented ones. The knowledge required 
for this reasoning is referred to as “N-agent 
knowledge”. 

On the other hand, each question allows 
assessment of a relationship between two 
agents. The term “bi-agent 1, refers to the 
process and knowledge used for each 
comparison. The result of a two-agent 
comparison is known as a “Partial Result”. 

A “mono-agent” phase may influence the 
Total Results in function of A’s wishes before 
die series of bi-agent comparison. 


5.2 Application to motorway traffic 
The Total Results for the Example 1 would be: 


Prevent-moving-out 

t 



Move-out 

t 

Move-out-list 

ft) 

Slow-down 

ta 

^low-down-list 

JL 


The decision-making rules for the bi-agent 
and then N-agent phases would be, for 
example: 


• if A is in the right-hand lane and X is in front 

of A in the right-hand lane and at lower 
speed and if safety distance has been 
reached 

then Move-out(X) := t 

Move-out-list(X) := (B) 

• if Move-out and Prevent-moving-out ~ 

then decelerate, choosing vehicles in Move- 
out-list 

• if Move-out then move out 

• if Prevent-moving-out then do nothing 
•if true then accelerate 


5.3 Selective backtrack 
The use of Results and the separation of 
conflict recognition from their overall 
processing makes a selective backtrack 


possible. Consequently, new information from 
agent B concerning an instant Tj, already 
planned, can be allowed for solely by 
comparison with B (see Figure 3). 



Figure 3. Selective backtrack for agent B 


If the new Partial Results for P at instant Tj, 
designated “new-Partial-B-Tj” equal Partial-B- 
Tj (i.e. the response to the new influence is the 
same as that to the previous influence - see 
Example 2.1) or if “new-Partial-B-Tj” is 
already part of “Total-Tj” (i.e. the response to 
the new influence had already been requested 
by at least one of the agents - see Example 
2.2), a total backtrack is pointless since the N- 
agent phase would produce the same 
conclusion. This selective backtrack is then 
sufficient for instant Tj. The same must then be 
repeated for each instant Tk between Tj and the 
current planned instant Tj. 

Since case 2 covers case 1, there seems to 
be no point in memorizing the Partial Results 
but only the Total Results (method named 
M3*). 

If, for any instant Tk between Tj and Tj, the 
results are not already included it can only be 
because a new response has been requested. 
The N-agent phase must, therefore, be 
triggered using a new Total Results which can 
be calculated in two ways: 

new-Total-Tk := (U Partial-X-T k ; X * B) 
© new-Partial-B-Tk 

new-Total-Tk := Total-Tk © Partial-B-Tk © 
new-Partial-B-Tk 

In either case, it would be useful to know 
certain Partial Results. 

The conflict recognition phase is, therefore, 
avoided for any agent other than B and the 
backtrack is still not total. If the resultant action 
is the same as that which would have been 

f enerated without the new information (see 
Example 2.3), we only need to continue 
selective backtracking on actions for instants 
after Tk. 
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1. A s plan : overtake C ; B’s plan : decelerate : the constraints B imposes on A are 
unchanged. 

2. A’s plan : slow down ; B’s plan : overtake A : the new constraint B imposes on A, 
i.e. forbidden to move-out, was already imposed by D. 

3. A’s plan : do nothing ; B’s plan : overtake A : the new constraint B imposes on A 
does not affect the action planned by A. 

4. A’s plan : overtake C ; B’s plan : overtake A : the new constraint B imposes on A 
generates a new action, i.e. slow down. A must replan the following instants. 


Example 2. Various selective backtrack levels 


However, if the action generated is new (see 
Example 2.4), a total backtrack from Tfc+j 
onwards is necessary since the new action 
could change the result of all the previous 
comparisons. 


5.4 Execution monitoring 
The execution monitoring of the plans 
generated can be done using the memorized 
Total Results and the selective backtracking 
possibilities to check that no agents, cause any 
infractions. 

The real behaviour of human drivers could 
be monitored as follows: 

• If man behaves approximately as the system 

expects then there will be no problem 

• Otherwise: 


If the man in question is driving our car, 
check whether the behaviour of the man 
is included in the prohibited behaviours 
memorized in the Total Results : 

• If there is infraction of one of these 
prohibitions, the driver could be 
warned (for a low-risk situation or a 
detected intention) or the system could 
take control to avoid an accident (for a 
dangerous situation). 

•Otherwise, complete replanning is 
required to adapt to this new 
behaviour (once the driver's intentions 
have been recognized...). 

If the man is driving another vehicle, 
which possibly does not have the 
system, it is necessary to run a selective 
backtrack for each instant T* between Tj 
and the current planned instant Tj to 
adapt our plan. 


6 Theoretical efficiency of the methods 
The theoretical costs of each of various 
methods (among 12 alternatives) were 
estimated making certain average assumptions 
about die multi-agent application and the way in 
which the databases or algorithms are designed 
(see [M ouro u and Fade, 91 b] an d [Mourou, 
92]). These costs are expressed as a mean 
number of influence tests in function of the 
number of other agents N, the maximum 
number of conflicts P and the mean number of 
influence tests Q used in a Ml conflict test One 
result is : 


Ml 

Q x N/2 x P 

M3* 

QxN 


M3* requires all possible comparisons to be 
done while Ml only requires comparisons on 
request However, it is more efficient since the 
influence tests are grouped. 

7 Main experimental results 
We simulated a highway with two lanes and 
carrying three vehicles fitted with a co-pilot and 
10 other preprogrammed vehicles. The three 
equipped vehicles are associated with three 
different processes linked through pipes. 24 
rules (10 bi-agent and 14 N-agent rules) are 
required with M3* to obtain an ideal response 
in “automatic mode” which respects safety 
distances and allows for the inertia of vehicles. 
The knowledge bases made it possible to write 
that for Ml. 

In this application, Q * 3 (relative position, 
relative speed, lane) and P = 3 (number of 
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booleans in the Results structure). N does not 
affect the relative performance. 

Ml and M3* gave results which matched 
those from the above formulas : M3* is 30% 
faster than Ml. 

In the best case, but which is also the most 
frequent, when the Partial Results calculated 
are included in the Total Results, M3* 
performed its selective backtracks in only 20% 
of the time required by Ml to completely replan 
(with N- 10). 

Conclusion 

The multi-agent planning/scheduling methods 
described in this article make its possible 
achieve a more flexible, fast and reactive 
system. The co-pilot can anticipate the near 
future by using the available time and without 
be obliged to wait for its neighbours because it 
can easily check and integrate a new 
information. 

In execution monitoring, a dangerous 
situation can be quickly detected. A backtrack 
of an agent and the selective backtrack of other 
agents allow to perform incremental 
rescheduling of the whole system. 
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Abstract 

A scheduling and resource management 
system named MAESTRO has been 
interfaced with a Space Station Module 
Power Management and Distribution 
(SSMPMAD) breadboard at Marshall Space 
Flight Center (MSFC). The combined 
system serves to illustrate the integration 
of planning, scheduling and control in a 
realistic, complex domain. This paper 
briefly describes the functional elements 
of the combined system, including normal 
and contingency operational scenarios, 
then focusses on the method used by the 
scheduler to handle real-time 
contingencies. 

I. Introduction 

For the past six years a team at Martin 
Marietta has been developing an 
integrated approach to scheduling, 
resulting in the implementation of a 
robust prototype scheduling system called 
MAESTRO [Geoffroy, Gohring & Britt, 1991]. 
During the same time frame another 
group at Martin Marietta has been 
building a hardware/software testbed to 
study various concepts in the automation 
of electrical power management, the 
Space Station Module Power Management 
and Distribution (SSMPMAD) system. In 
1988 an initial version of the SSMPMAD 
system integrated with MAESTRO was 
delivered to Marshall Space Flight Center. 
Since then both the SSMPMAD system and 
the scheduler have gone through several 
revisions, and a major delivery of new 
software occurred in June of 1991. This 
paper describes that combined system, 
highlighting those aspects of it that 
illustrate concepts in integrated planning, 
scheduling and control. We focus on the 
replanning and rescheduling processes 
used in MAESTRO to respond to real-time 
contingencies, unexpected changes in the 
state of the power system that cause a 
schedule currently being executed to 
become invalid. 
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Section II defines some tenns used in the 
rest of the paper. Section III describes the 
functional architecture of the system. In 
section IV are presented two operational 
scenarios, one for normal operations and 
one which describes a possible 
contingency. Section V provides a 
description of the processes carried out by 
the scheduler to effect real-time 
replanning and rescheduling, including 
timing issues. In section VI we conclude 
with indications of possible future 
directions for this research. 

II. Definitions 

For the purposes of this discussion we will 
make use of the following restricted 
definitions. Planning is defined to be the 
process of specifying goals to be achieved 
onboard a spacecraft, and further, of 
specifying the activities which will 
achieve those goals. This involves 
determining these activities' structure as 
well as constraints on the execution of 
them. Activities , in turn, are defined to be 
sequences of subtasks which accomplish 
the desired goal. Scheduling is defined to 
be the process of selecting some subset of 
these activities and specifying exact 
start/end times and resource assignments 
for their component subtasks. A valid 
schedule is a specification of start/end 
times and resource assignments for a set 
of activities such that the activities may be 
executed as scheduled. A contingency 
arises when a previously valid schedule 
becomes invalid as a result of a change in 
the assump tions upo n which that schedule 
was based. The term real-time is used here 
to mean "during execution of the activities 
on a schedule”. This does not have the 
connotation from control theory that a 
real-time event must be responded to 
within microseconds, but rather is used to 
differentiate between actions that are 
occurring at the moment as opposed to 
those that will occur at some point in the 
future. A load is the use of electrical 
power by a piece of equipment. 


The authors would like to acknowledge John Gohring of Martin Marietta Western Internal Systems and Joel Riedesel of Martin 
Marietta Astronautics Group for their significant contributions to this report and to the work described herein. 
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III. Functional Architecture 
Figure 1 depicts the functional elements of 
the combined SSMPMAD/MAESTRO system 
and relationships among these elements. 
Briefly, the Activity Editor is used to create 
definitions for activities which 
accomplish goals desired by the user. 
MAESTRO is used to select and schedule a 
subset of these activities, and to save the 
resultant schedule(s) out to files. The 
Transaction Manager (TM) serves as a 
communications port, facilitating specific 
types of communications between 
MAESTRO and the rest of the system during 
breadboard operation. The Front End Load 
Enable Scheduler (FELES) creates 
schedules of power system events (such as 
closing switches) from saved schedule 
files. The Communications and 
Algorithmic Controller (CAC) distributes 


schedules among Load Centers (LCs), into 
which are incorporated Lowest Level 
Processors (LLPs). These LLPs actually 
control hardware switches on the power 
system breadboard, as well as monitoring 
the states of various sensors distributed 
throughout the system. The Fault 
Recovery And Management Expert System 
(FRAMES) performs fault isolation, 
diagnosis and recovery for the power 
system, and communicates with the 
scheduler during real-time contingencies. 
The Load Priority List Management System 
(LPLMS) maintains a list of active loads in 
a prioritized order such that if there is a 
need to quickly reduce power 
consumption in a portion of the 
breadboard, loads can be shed (turned off) 
in an order that minimizes the impact of 
this load shedding. 



Figure 1. Functional architecture of the MAESTRO/SSMPMAD combined system. 


A portion of the actual power circuits on 
_ the breadboard is depicted in figure 2. 

Note that several 1 -kilowatt Remote Power 
is Controllers (RPCs) can be attached to a 

single 3-kilowatt RPC. Thus it is possible to 
m overload an intermediate RPC without 


overloading any of the lower-level RPCs 
connected to it. For this reason it is 
necessary to represent the entire power 
path for each power-using resource to the 
scheduling system, rather than just 
representing total power consumed by 
each activity. 
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Figure 2. Representative schematic of a portion of the SSMPMAD breadboard. 


IV. Operational Scenarios 
Normally, a user will interact with the 
activity editor to create a set of activities to 
be scheduled, saving these activities' 
definitions in an activity library. In that 
or another session, the user will run the 
scheduler to create one or more initial 

schedules of these activities. These 
schedules will be saved into a schedule 

library. When a user wishes to operate 
the power system breadboard, s/he uses 
the SSMPMAD interface to select a saved 
schedule, initialize the system and execute 
that schedule. The FELES first obtains a 
saved schedule and translates a portion of 
it (roughly one-half hour of activity) into 
a series of power system events, 
specifying at what times and power levels 

each RPC is to be turned on. The LPLMS 

takes this schedule of power system events 
and creates a list of loads to shed in an 
emergency power reduction. The event 
schedule and priority list are transmitted 
to the CAC, which distributes them among 
the LLPs as appropriate. The CAC also 
maintains a system clock, coordinating 
timing for the various elements. 


Execution of the distributed schedule 
proceeds with the LLPs directing the RPCs 
to close and open switches at the times 
specified by their respective event 
schedules. The RPCs monitor voltage, 
current, temperature and other 
parameters of their operations. 

Prior to the expiration of the timeline 
increment being executed, the FELES will 
acquire another increment from the saved 
schedule, translate it into power system 
events, and transfer it to the CAC, which 
distributes it to the LLPs. At a specified 
time, the LLPs stop executing the old 
increment event list and begin executing 
the new one. 

When an anomalous condition (such as 
over-current or under-voltage at a 
switch) is detected by one of the RPCs, it 
automatically takes a safing action, if 
possible. The LLP controling it reports 
this event to FRAMES, which gathers 
together all available information about 
the fault, isolates it, and compiles a list of 
system configuration status changes 
resulting from the fault. These changes 
can include a load being switched to a 
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redundant power source (redundancy 
switching), an RPC going out of service, 
the deliberate shutdown of a load to reduce 
power consumption (load shedding), or a 
reduction in power available at an RPC 
and the expected duration of that 
reduction. This list of changes is then 
communicated to the scheduler, which 
revises the activity schedule to reflect the 
changes and makes the new schedule 
available to the FELES. It creates a new 
event list, which is distributed to the LLPs 
along with a time tag indicating when to 
begin executing the new schedule. 

V. The Real-Time Rescheduling Process 
When a power system anomaly occurs, 
MAESTRO will get a set of information 
from FRAMES throught the TM. This 
information will include the current time 
in addition to redundancy switch, load 
shed, power availability change, and RPC 
out-of-service messages. These messages 
will include the time the event occurred, 
and if applicable the duration of the 
change. MAESTRO follows a three-step 
process to handle these messages and 
revise the schedule. It 1) modifies the 
schedule to reflect changes made to it by 
the power system and to remove resource 
and temporal constraint violations for 
activities not yet begun, 2) tries to find 
ways to create and schedule continuations 
for interrupted activities, and 3) tries to 
schedule any activities that can take 
advantage of the resources released by the 
interruption of others. The first step 
results in a valid but possibly not very 
efficient schedule. It is carried out as 
quickly as possible to ensure that a 
workable schedule can be in place soon, 
reducing the likelihood that adherence by 
the power system to the old (invalid) 
schedule will result in a cascade of faults 
registered by that system. The second and 
third steps will only be attempted if there 
is sufficient time to get something useful 
done. Management of its own computation 
time is a difficult issue for a real-time 
rescheduler. It must project a time when 
it will have a valid schedule available, 
including the time it takes to transmit that 
schedule to the entities responsible for 
carrying it out, then not make changes to 
the schedule (other than those already 
made by the power system) that would 
need to be acted upon before they are 


received by the power system. For 
example, if at 10:00 a contingency occurs, 
and the scheduler determines that an 
interrupted activity can be continued at 
10:05, but this information cannot be 
transmitted to the power system until 
10:08, then the schedule is invalid the 
moment the system begins to execute it. 
In this example the scheduler could 
specify that the activity be continued at 
10:08, but not before. 

The actual structure used to control the 
three-step process mentioned above is a 
prioritized list of command queues. As 
information comes in from FRAMES, it is 
routed to one of several command queues, 
for action as soon as MAESTRO has nothing 
more important to take care of. Resource 
availability changes appear in one queue, 
while redundancy switches are in another 
and load sheds in a third, for example. 
MAESTRO will be in a wait state until 
something appears on one of its command 
queues, at which time it will process a 
command from the highest priority queue 
that has an item, then check all the 
queues again for new items, returning to 
the wait state when no items remain. 

MAESTRO will add items to its command 
queues as a result of its own processing. 
Handling a resource availability change, 
for example, will cause MAESTRO to add a 
command to check for resource constraint 
violations. If a violation is found and an 
activity interrupted, MAESTRO will add a 
command to try to plan and schedule a 
continuation of that activity. 

Activity continuation is the single 
automated planning function within 
MAESTRO. When initially creating 
activities, the user specifies ways and 
conditions under which each subtask may 
be continued if it is temporarily 
interrupted. Three continuations are 
currently represented for each subtask. 

. , These are effectively operators that can be 
selectively applied to achieve the goal of a 
completed activity performance. First, the 
unexecuted portion of an interrupted 
subtask may be skipped, with a parameter 
stating how much time the subtask must 
execute prior to the interruption. A data 
collection subtask could be terminated 
early and data analysis begun, for 
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example. Second, a subtask may be 

continued after a sufficiently brief 

interruption. Finally, the interrupted 
subtask may be started over again, making 
use of states set by previous subtasks but 
not using the progress gained in the 
interrupted subtask. 

The scheduler will create a new activity 
model appropriate for a particular type of 
continuation using information from the 
interrupted activity and possible 
continuations specified by the user for 
that activity. Each of the above 
continuations has different implications 
for the rescheduling of the subtasks 
following the interrupted one, so MAESTRO 
must try various options in order to find a 
viable placement for the new activity. 
MAESTRO can represent temporal 
constraints between activities, sometimes 
necessitating the consideration of more 
than one continuation model at once. This 
complexity combines with the time 
limitations on rescheduling to prohibit 
MAESTRO from finding the "best" way to 
continue an activity - it simply accepts the 
first viable continuation found. Attempts 
are heuristically ordered such that 
higher-value continuations are tried 
earlier, however. Note that in many cases 
no continuation will be possible, in which 
case the work done to represent the 

current state of the system is all that can 
be accomplished for a particular activity. 
Note also that safing actions are not 

scheduled but rather are carried out 

immediately and automatically by the 
subsystems involved. 

As each continuation attempt is made, the 
system consults the system clock, 
abandoning further attempts at the point 
where they would cause changes made to 

the schedule to be unimplementable. 
When all continuation attempts have been 
tried (and there may be none tried), if 
there is still time, the scheduler will 
attempt to add new performances of 
activities to the schedule. System time is 
checked after each schedule addition, and 
this process ends when time runs out or 
no more activities can be added to the 
schedule. At that point the schedule is 
made available to the FELES, and schedule 
execution proceeds as previously 
described. 


VI. Future Directions and Related Work 
Worit is continuing on MAESTRO, as it is on 
SSMPMAD. The scheduler needs to be 
enhanced to manage the timing and 
consistency issues that arise when a user 
wishes to alter a schedule that is currently 
executing. We also intend to enhance the 
representational as well as computational 
power of the system. The current methods 
for finding a way to continue an 
interrupted activity are cumbersome and 
depend too much on initial user input into 
the representation of the subtasks. A 
more appropriate method would be to have 
an intelligent system monitoring each 
experiment or other major activity, with 
the capability to plan continuations based 
on an accurate assessment of the state of 
the activity. 

We have begun a task similar to the 
MAESTRO/SSMPMAD integration for 
Kennedy Space Center under the 
Advanced Launch Processing (ALP) 
contract. In that effort we will build a 
system executive capable of coordinating 
the actions of multiple Knowledge-Based 
Autonomous Test Engineer (KATE) systems 
[Parrish & Brown, 1991]. These systems 
are used to monitor and control individual 
launch vehicle subsystems during testing 
and launch, but are independent of one 
another. The system r executive will 
interface with the Kate systems as well as 
with higher-level launch flow 
management functions, enhancing 
integrated vehicle systems tests and 
reducing launch costs. 
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This paper describes an approach to planning and 
scheduling in uncertain domains. In this approach, a 
system dividesa task on a goal by goal basis into re- 
active and deliberative components. Initially, a task is 
handled entirely reactively. When failures occur, the 
system changes the reactive/deliberative goal division 
by moving goals into the deliberative component. Be- 
cause our approach attempts to minimize the number 
of deliberative goals, we call our approach Minimal De- 
liberation (MD). Because MD allows goals to be treated 
reactively, it gains some of the advantages of reactive 
systems: computational efficiency, the ability to deal 
with noise and non-deterministic effects, and the ability 
to take advantage of unforseen opportunities. However, 
because MD can fall back upon deliberation, it can also 
provide some of the guarantees of classical planning, 
such as the ability to deal with complex goal interac- 
tions. This paper describes the Minimal Deliberation 
approach to integrating reactivity and deliberation and 
describes an ongoing application of the approach to an 
uncertain planning and scheduling domain. 

INTRODUCTION 

The AI problem of automatically achieving goals has 
been redefined in the last few years. The classical plan- 
ning problem can be broadly characterised as finding 
a set of operators together with sufficient constraints 
such that when applied to some initial state the result- 
ing state provably satisfies some goal relation. However, 
this is a narrow view of what is now seen as a more gen- 
eral problem. Recently, there has been a great deal of 
interest in reactivity as a model of action [Suchman87]. 
While the classical view of planning has been shown 
to have computational problems [Chapman87]; from a 
different perspective one might instead blame our fail- 
ure to conceive of alternative frameworks for modeling 
world changes and formalisms for action selection. 

Reactivity takes a different, more efficient view of ac- 
tion selection. Pure reactivity fundamentally gives up 
the idea of projecting the results of actions. Instead an 
agent reacts to the current state of affairs in the world 
as directly perceived by sensors. In a sense, reactivity 
is a hill-climbing action-selection model. The evidence 
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taken into account in the selection of an action is neces- 
sarily local (i.e., the current readings of sensors). Based 
on this purely local information an action is taken that 
may have resounding global ramifications, fooling the 
agent into climbing to the top of a locally steep foothill 
from which state the goal is unachievable. 

This phenomenon often occurs in the form of inter- 
acting sub-goals both in planning and scheduling. In a 
planning context, as you exit the parking lot on your 
way home from work you may prefer a right turn (it 
more directly leads toward your house, it is less ex- 
pensive than a left turn across traffic, etc.). However, 
in the context of a second goal of picking up a loaf of 
bread, it may be better to turn left, taking you past a 
supermarket on the way. In a scheduling context, inter- 
actions occur through resource contention. A job may 
finish earlier if allowed to execute one of its subtasks 
at a certain time, but the overall schedule may suf- 
fer. Approaches that address managing such problems 
of purely reactive systems include: developing a the- 
ory of benign environments in which a reactive agent 
may be more certain that its reactive inclination will 
meet with success [Agre88, Hammond9Q]; the integra- 
tion of classical planning with reactivity [Drummond90, 
Kaelbling86, Turney 89]; and application of machine 
learning to this end [Gervasio90, Mitchell90, Laird90]. 
These approaches begin with what is essentially a clas- 
sical planner and, guided by experience, result in the 
formulation of reactive components as well. 

This research approaches planning and scheduling 
from a different point of view. Instead of learning to in- 
corporate reactivity into a classical deliberative frame- 
work, we propose incorporating minimal classical de- 
liberation into an initially purely reactive system. As 
failures are encountered, the system utilises its world 
model to explain why the desired state of affairs was 
not brought about by the executed actions. 

In the case of a failure of a reactive goal, the fail- 
ure could be due to a faulty set of reactions or due to 
uncertainty in the effects of actions or schedules. In 
the case of failure of a deliberative goals, the failure 
must be due to interference from a reactive goal. In 
the case of uncertain effects causing the failure of a re- 
active goal, deliberation can be used to attempt to im- 
prove the plan. In the case of reactive interference in a 
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reactive or deliberative goal, the offending reactions are 
inhibited by moving the associated goal into the delib- 
erative component, where the negative goal interaction 
will be considered and avoided. 

In this way the purely reactive system adopts just 
enough deliberation to avoid goal interaction pitfalls. 
Since deliberation occurs only in reaction to observed 
failures, (i.e. the resultant plan remains uncommitted 
on those goals not appearing in the failure trace) this 
approach will generally retain some level of flexibility 
by avoiding a rigid classical plan or schedule for all 
of the goals. Thid flexibility allows the MD approach 
will retain some of the benefits of reactivity: toler- 
ance of noise, uncertainty, and incomplete knowledge 
as well as computational efficiency. Yet the MD ap- 
proach also benefits from its ability to fall back upon 
traditional deliberative planning. It gains the abil- 
ity to solve problems which require simultaneous con- 
sideration of multiple interacting goals. Additionally, 
through explanation-based learning(EBL), it gains the 
ability to cache and generalize decisions made in the 
plan construction process. As with traditional EBL, 
the learned deliberation molecules allow a system to 
find plans more quickly. But more importantly, these 
deliberation molecules allow a system to avoid repeat- 
ing the failures resulting from the short-sighted decision 
of the reactive component. 

These benefits of coordinating reactivity and delib- 
eration are relevant to both planning and scheduling 
issues described in this paper. Reactivity can take ad- 
vantage of unforseen opportunities. In, planning this is 
the ability to take advantage of fortuitous conditions in 
the world state. In scheduling, this is the ability to take 
advantage of unforseen resource availability. Another 
strength of reactivity is the capability to deal with un- 
certainty and noise. In planning this means the ability 
to deal with uncertain action effects and/or world state. 
In scheduling this means the ability to deal with uncer- 
tain resource consumptions and availabilities. A third 
strength of reactivity is its computational efficiency due 
to avoidance of explicit projection. In planning, this 
means not having to explicitly determine future world 
states. In scheduling, this means not having to explic- 
itly determine future resource utilization. The principal 
strength of deliberation is the ability to deal with ar- 
bitrary goal interactions by searching the space of pos- 
sible plans and/or schedules. In planning this means 
being able to deal with complex precondition and effect 
interactions between goals. In scheduling, this means 
being able to deal with difficult resource interactions. 

There are a number of assumptions underlying the 
MD approach. First, we assume that the cost of fail- 
ures is sufficiently low so that the cost of failures in- 
curred while acting reactively is outweighed by the over- 
all gains in flexibility and efficiency from reactivity. A 
corollary to this assumption is that the reactive compo- 
nent is sufficiently competent to solve the majority of 
the goals. Without this constraint, the MD approach 
would incur the cost of numerous failures only to end 


up doing primarily deliberative planning. Second, we 
assume the presence of domain models to allow the sys- 
tem to fall back upon classical planning as well as per- 
mitting use of EBL. Third, the system must be allowed 
multiple attempts to solve a problem. 

THE MD ARCHITECTURE 

The system architecture advocated by the MD ap- 
proach is that of an interacting set of components: a de- 
liberative element, a reactive element, and a learning el- 
ement. The deliberative element is a conventional plan- 
ner which constructs classical plan/schedule molecules 
for goal conjuncts requiring deliberation. By ana- 
lyzing the precondition and schedule interactions and 
performing extensive search deliberation can resolve 
the goal interactions. The learning element uses EBL 
[DeJongSfl, Mitchell86] to learn general plan/schedule 
molecules which indicate how to achieve a set of goals 
by designating a reactive/deliberative goal allocation 
and a set of actions for the deliberative goals. 

The reactive element proposes actions using a shal- 
low decision model of reaction rules. Each reactive rule 
specifies a set of state conditions and resource require- 
ments which specify an action as appropriate to exe- 
cute. Multiple actions may be executed during a single 
timestep if resources allow. In most cases, failures in 
the reactive component will be due to goal interactions. 
Reaction rules consist of in terru pt rules, which cause 
actions to be executed regardless of the other actions 
the agent is taking (i.e. actions determined by the de- 
liberative component), and suggestion rules, which are 
executed when the system has no current pending ac- 
tions. Thus, interrupt rules represent actions to take 
advantage of immediate opportunities or avoid dan- 
gerous situations regardless of the current deliberative 
plan, while suggestion rules direct activity when the 
system is confronted by a set of goals, and does not 
have a current plan. 

Every reaction rule is defined with respect to a goal, 
and can only apply when its goal matches a reactive 
goal of the system. Thus, a reaction can be overridden 
by the deliberative component by removing the trigger- 
ing goal from the set of reactive goals and planning for 
the goal dellberatively. Thus, in our architecture^ there 
are three levels of priority: interrupt rules, the action 
advocated by the current plan, and suggestion rules. 
Within a given priority level, if more than one actioilir 
applicable, the system chooses one arbitrarily but de- 
terministically (e.g. the same set of goals and st ate will 
produce the same action). For example, in a delivery 
domain, interrupt rules might trigger when the truck is 
at the location of one of its deliveries. This can occur in 
the midst of executing a decision molecule constructed 
by the deliberative component, and it results in actions 
other than those in the decision molecule. An example 
suggestion rule would be one which causes the truck 
to move towards the closest delivery site if it does not 
have a decision molecule to guide it otherwise. 
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THE MD APPROACH 

In the MD approach, a system originally acts based 
upon a shallow, simple decision model. Through expe- 
rience, the system gradually acquires a set of decision 
molecules which allow it to plan past local maxima 
encountered by the shallow decision model. Because 
of this progression, we describe the MD approach as 
“becoming decreasingly reactive”, as the proportion of 
goals the system solves by deliberation increases (where 
we also consider as deliberative the compiled decision 
molecules created by the deliberative element). Even- 
tually, for a fixed distribution of problems, the system 
will learn a set of decision molecules sufficient to allow 
it to solve the problems occurring in the distribution. 
Furthermore, because the MD approach uses EBL, the 
system also learns to avoid a general class of failures 
relevant to a particular plan, thus reducing the number 
of failures required to learn a satisfactory set of plans. 

A problem consists of a conjunction of goals, and the 
task of a system in the MD approach is to divide the 
goals into a deliberative set and a reactive set such that 
the^ goals are all achieved with the minimum amount of 
deliberation and maximum amount of flexibility pos- 
sible. A plan to solve a conjunction of goals is thus 
a composite plan/schedule which consists of a decision 
molecule, constructed by the deliberative component to 
solve the set of deliberative goals, and a set of reactive 
goals to be achieved by the reactive component. The 
MD algorithm is shown below: 

Givsn a problem consisting of: 

G “ a sat of problem goals 
I - the initial state 

REAC G 
DELIB O 

loop 

PLAI Classical .Planner (DELIB , I) 

Execute (PULS, REAC) 

if all goals achieved return SUCCESS 
else if REAC - {} return FAIL 

else 

for each goal in REAC 

if <goal not achieved> OR 

<reactive action in pursuit of goal 
interfered with another goal G’> 

then 

REAC :« REAC - goal 
DELIB : ■ DELIB + goal 

go loop 

if SUCCESS then generalise successful plan 

The key to the MD approach is the blame assignment 
process. In general, failures are due to interactions be- 
tween subgoals, as the reactive methods are intended 
to be sufficient to achieve goals without interference. 
Interference can occur at the planning level (due to an 
action in service of one goal clobbering a protection in 
service of another goal) and at the scheduling level (re- 
source expenditures due to one goal causing a resource 
failure for another goal). 


Blame assignment consists of determining which 
goals are involved and then using this information to 
reduce future failures due to goal interactions. In goal 
identification process, there are planning failures and 
scheduling failures. Each of these failure types (plan- 
ning, scheduling) can cause a goal to be identified as 
relevant to a goal analysis. In the first way, a goal G 
fails, likely due to actions in service of another goal. 
This goal is called a confiictee and is considered in the 
analysis described below. This set of circumstances can 
be detected by checking if goals are achieved at the end 
of execution (infinite looping is detected by an execu- 
tion limit). The second relevant goal type is a conflicter 
goal. A goal G is deemed a conflicter if an action A in 
service of G caused a failure of another goal H. In the 
context of planning, this occurs if the confiictee H is 
a deliberative goal and A clobbers a protection in the 
plan to achieve H. In a scheduling context a goal G is 
deemed a conflicter if an action A in service of G was 
the largest consumer/user of a resource R which caused 
a scheduling failure for a deliberative goal H. 

We now describe how this determination of goal inter- 
ference is used to modify the allocation of reactive and 
deliberative goals. If a reactive goal Gl fails without 
interference, it is moved to the deliberative component 
and thusly will be achieved by the classical planner and 
scheduler. A deliberative goal Gl cannot fail without 
interference as the planner performs full projection. In 
the case of a goal failing due to interference from a sec- 
ond goal G2, there are four cases, Gl and G2 reactive, 
Gl reactive and G2 deliberative, Gl deliberative and 
G2 reactive, and Gl and G2 both deliberative. How 
each of these cues is treated is described below. 

1. Because the deliberative element performs full pro- 
jection, two deliberative goals cannot interfere, thus 
the failure case of both Gl and G 2 deliberative can- 
not occur. 

2. If Gl is a reactive goal, and G2 deliberative, the MD 
approach will move Gl to the deliberative goal set 
and the classical planner will ensure that the negative 
goal interaction between Gl and G2 will be avoided. 

3. If Gl is deliberative and G2 reactive, then due to 
the blame assignment scheme G2 will be moved into 
the deliberative component. In the next cycle both 
Gl and G2 will be delegated to the deliberative com- 
ponent and the interaction will be considered and 
avoided. 

4. If Gl is a reactive goal and it has been thwarted 
by another reactive goal G2, the blame assignment 
scheme will move Gl to the deliberative component. 
If in the next cycle G2 still interferes, it is an example 
of case 3 above and will be treated accordingly. 

Thus the process of moving more goals to the deliber- 
ative component continues until the system converges 
upon a set of deliberative goals for which the planner 
and scheduler constructs a plan and schedule which in 
combination with the reactive element achieves all of 
the problem goals. 

This classical plan is then generalized using EBL, 
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with the reactive goals being generalized to a de- 
fault level. This resultant plan structure (and reac- 
tive/deliberative division) can then be used to solve 
future problems as follows. When problems are ini- 
tially posed to MD, it begins by attempting to match 
the goals and initial conditions to an existing decision 
molecule. If a matching decision molecule exists, it is 
used in an attempt to solve the plan. If all such match- 
ing molecules fail, the system attacks the problem en- 
tirely reactively and the entire MD approach is called 
from scratch. 

EVALUATION 

The MD approach has been implemented for a simple 
delivery planning domain [Chien91]. We have extended 
the failure analysis algorithm and are currently imple- 
menting this newer version of MD for a more complex 
mathematical planning and scheduling domain. This 
ongoing implementation is the one described in this pa^ 
per. In this mathematical domain, each goal can be 
achieved by the execution of a number of actions. Each 
action has a randomized number of resource require- 
ments, and possibly state requirement preconditions for 
each of the resources (e.g., a value for a predicate on 
the resource). Planning goal conflicts occur through in- 
compatible resource state requirements. Scheduling re- 
source contention occurs through goals competing for 
resources. Uncertainty exists through a random ele- 
ment in duration of primitives (and thus resource us- 
age). 

We plan to test our architecture by generating do- 
main theories which vary a number of parameters which 
will affect the overall scheduling and planning goal in- 
teraction rate. The domain parameters are: 1) the # 
of resource types (affects resource and conflict rate); 2) 
average number of resources each action uses (affects 
resource conflict rate); 3) frequency and types of re- 
source conditions (affects planning conflict rate); and 
4) # of preconditions per primitive (affects planning 
conflict rate). Finally, we plan to vary the amount of 
action duration uncertainty, which affects the amount 
of benefit gained by deferring decision-making. 

In order to compare with the MD approach, we are 
currently implementing a fully deliberative planner and 
scheduler. This comparison classical system simply del- 
egates all of the goals to the deliberative component. 

The metrics which we plan to use to evaluate the 
plans produced by the two systems are: l) total CPU 
time required for decision-making; 2) robustness of the 
schedule (% of goals achieved by deadlines); 3) average 
time to completion of individual goals; and 4) average 
time to completion of all goals. These metrics will be 
evaluated for different combinations of the domain pa- 
rameters described above. 

DISCUSSION 

This research is preliminary, and there are a number 
of outstanding research issues. One difficult issue is 
determining the correct level of generalization for the 


reactive portion of any plan /schedule. Because reac- 
tive actions are undetermined, analyzing generality of 
the goal achievement methods is difficult. While com- 
mitting the planner to the same general set of actions 
used by the reactive component in the current problem 
would allow EBL on the action trace, it commits the 
planner to the same general set of actions - losing the 
flexibility allowed by reactivity and forcing a possibly 
expensive causal analysis of the example. Yet another 
approach would be to generalize the reactive portion ag- 
gressively and allow later learning to either reduce the 
level of generality or learn more specific plans which 
would shadow the over-general plan in cases where it 
was inappropriate. 

One view of the MD approach is that of using delib- 
eration to learn patches to a set of reactive rules. In 
this view our techniques allow for encoding of a quick 
and dirty set of reactive rules which solve the majority 
of problems. Through learning, a set of patches can 
then be constructed to allow these imperfect rules to 
solve a given distribution of problems. 

Another interesting issue for examination is the 
tradeoff between reactivity and deliberation in the 
purely reactive component. Currently, the reactive 
component does no projection before interrupting the 
current plan and the deliberative element perforins full 
projection. While ideally both approaches components 
would be less extreme, the same general mechanisms 
for integrating deliberation and reactivity would apply. 

Another possible approach to integrating delibera- 
tion and reactivity is to use the same failure-driven 
method for splitting goals between the reactive and 
deliberative component to learn control rules specify- 
ing allocation of goals to the deliberative and reac- 
tive components. While we feel that the current MD 
macro-based approach better preserves the notion of a 
plan/schedule context in that the deliberative actions 
selected may impact the success of the reactive com- 
ponent, this is a larger issue involving the operational- 
ity /generality tradeoff. 

Another issue is that of controlling moving interact- 
ing goals into the deliberative component. Managing 
the tradeoff between more expensive (and likely more 
accurate) failure analyses and more heuristic (and likely 
less accurate) goal analyses is an issue for future work. 

RELATED WORK 

Drummond and Kaelbling [Drummond90, Kaelbling86] 
describe anytime approaches wherein planning is used 
to constrain the reactions, which are always available 
for deciding on actions. [Tumey89] interleaves plan- 
ning and execution by allocating some predetermined 
amount of time to each phase in turn, while [Hanks90] 
uses the constraints of urgency and insufficient informa- 
tion to determine when to pass control to the reactive 
component. In these approaches, any goal may thus 
be addressed reactively or deliberatively. In contrast, 
a system in the MD approach initially addresses all its 
goals reactively but incrementally learns which goals 
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require deliberation to avoid negative interactions and 
which goals can be addressed reactively without pre- 
venting the achievement of other goals. Thus, the MD 
approach can guarantee the achievement of its goals, 
which the others in general cannot. 

Guaranteed goal achievement is similar to ideas pre- 
sented in [GervasioQO, Martin90]. In [Gervasio90], the a 
priori (deliberative) planner must construct an achiev- 
ability proof for each deferred goal, while in [Martin90j, 
the strategic (deliberative) planner assigns the reac- 
tive planner those goals which the reactive planner has 
proven itself capable of handling. In contrast, in the 
MD approach, each goal is considered achievable during 
execution until experience shows otherwise. The MD 
need not prove achievability but instead incurs failures 
to determine which goals must be deliberated upon. 

In [Mitchell90, Laird90] systems become increas- 
ingly reactive by compiling deliberative decisions into 
stimulus-response rules/chunks. As the decision 
molecules learned by MD are compiled schemata, MD 
becomes increasingly reactive in the same sense. How- 
ever, it becomes decreasingly reactive in the sense that 
it initially addresses all goals reactively, but gradually 
learns to address particular goals deliberatively. In 
contrast, since Theo-Agent and SOAR derive all their 
rules/chunks from deliberative plans, they always ad- 
dress their goals purely deliberatively. 

TRUCKER [Hammond88] learns to optimize its 
planning from successful opportunistic problem- 
solving. While in the MD approach, a system learns 
which goals interact negatively and modifies its plan- 
ning behavior to deliberate over these goals and avoid 
the interaction, TRUCKER learns which goals interact 
positively and modifies its planning behavior to take 
advantage of this interaction. Other work on learn- 
ing from failure deals with purely deliberative plans, in 
contrast to the composite plans in the MD approach. 

CONCLUSION 

This paper has presented an approach to integrating 
reactivity and deliberation in planning and scheduling 
in uncertain domains. In this approach, called Min- 
imum Deliberation (MD), the problem-solver initially 
attempts to solve all goals reactively. When the sys- 
tem encounters failures it responds by moving reactive 
goals into the deliberative component. By performing 
this refinement, the system extends its analysis of the 
problem minimally until the reactive component can 
solve the remainder of the goals. Resultant successful 
plans are then generalized using a combination of EBL 
and default generalization information. By introducing 
deliberation minimally, the MD approach retains some 
of the benefits of reduced computation and flexibility 
from reactivity while still being able to fall back upon 
deliberation to solve complex interactions. 
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Abstract 

The planning problem has traditionally been treated separately 
from the scheduling problem. However, as more realistic do- 
mains are tackled, it becomes evident that the problem of de- 
ciding on an ordered set of tasks to achieve a set of goals cannot 
be treated independently of the problem of actually allocating 
resources to the tasks. Doing so would result in losing the ro- 
bustness and flexibility needed to deal with imperfectly mod- 
eled domains. Completable scheduling is an approach which 
integrates the two problems by allowing an a priori planning 
module to defer particular planning decisions, and conse- 
quently the associated scheduling decisions, until execution 
time. This allows a completable scheduling system to maxi- 
mize plan flexibility by allowing runtime information to be 
taken into consideration when making planning and schedul- 
ing decisions. Furthermore, through the criterion of achievab- 
ility placed on deferred decisions, a completable scheduling 
system is able to retain much of the goal-directedness and 
guarantees of achievement afforded by a priori planning. The 
completable scheduling approach is further enhanced by the 
use of contingent explanation-based learning, which enables 
a completable scheduling system to leam general completable 
plans from example and improve its performance through ex- 
perience. Initial experimental results show that completable 
scheduling outperforms classical scheduling as well as pure 
reactive scheduling in a simple scheduling domain. 

Introduction 

The planning problem has traditionally been treated separate- 
ly from the scheduling problem. Planning deals with the de- 
termination of an ordered set of actions for achieving a set of 
goals. In the context of scheduling domains, planning deals 
with determining an ordered set of tasks for a set of jobs. In 
contrast, scheduling deals with the actual assignment of tasks 
to machines and is generally concerned more with finding the 
best cf several alternative task-machine assignments than 
with finding a particular task-machine assignment. As more 
realistic scheduling domains have been addressed, however, 
it has become apparent that planning and scheduling cannot 
be treated independently. The complexity cf real-world do- 
mains makes perfect characterizations difficult to construct 
and often unwieldy. To this end, researchers in both planning 
and scheduling have investigated reactive approaches which 
allow for decision-making during execution [Agre87, Fir- 
by87, Kaelbling88, Muscettola90, Ow88, Prosser89]. 

However, the classical approach of first doing planning and 
then scheduling still remains a problem. Consider giving a 
classical system in a process planning domain the job of man- 
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ufacturing a particular part. Its planner must decide a priori 
on an ordered set of actions or operations which will result in 
the conversion of the raw material into the desired product 
Its scheduler is then given the responsibility of actually allo- 
cating resources and carrying out the operations on the ma- 
chines. However, because the planner commits the system to 
a particular set of operations, the scheduler may not execute 
the best plan. For example, the planner may not be able to 
guarantee that the efficient new milling machine will be avail- 
able and sochoose the older, slower one. However, during ex- 
ecution, the more efficient machine may turn out to be avail- 
able, but the scheduler does not have the option to alter the 
plan. Furthermore, an over-constrained classical plan may 
prevent quick fixes to unpredictable runtime situations. For 
example, a chosen drill bit may turn out to be unavailable, thus 
rendering invalid those subsequent actions involving a corre- 
spondingly sized bolt and wrench. A simple fix would - be to 
use a different drill bit, and switch to the appropriately sized 
bolt and wrench, but a scheduler with a completely-deter- 
mined plan does not have this capability. 

A purely reactive approach, with no a priori planning, has 
its own problems. Most manufacturing domains are fairly 
well-behaved; there is much information available a priori 
and fairly accurate predictions can be made about the behav- 
ior of the world under particular circumstances. A purely 
reactive approach which performs no projection cannot take 
advantage of this information to constrain its actions and pre- 
vent thrashing. With the planning problem and the scheduling 
problem combined, the runtime decision-making problem 
also becomes a larger and more complex one. 

This research began as an attempt to address the problems 
with classical, apriori planning and pure reactivity. In partic- 
ular, completable planning was developed as an approach 
which combined the goal-directedness and provably correct 
plans cf classical planning with the flexibility and ability to 
utilize runtime information afforded by reactive planning. 
This enabled a completable planner to more efficiently deal 
with the problems arising from imperfect a priori information 
while still retaining the benefits cf planning beforehand in rel- 
atively well-behaved environments. More recently, we have 
been investigating scheduling, and we have found that many 
of the techniques originally developed as part cf the complet- 
able approach to planning are also useful fox solving some cf 
the problems which arise from scheduling in realistic do- 
mains where perfect a priori information about the environ- 
ment is unavailable. For example, in the scheduling scenario 
above, a completable scheduling system could defer the deci- 
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sico of which milling machine to use as well as the choice of 
bit, bolt, and wrench sizes. During execution, it can then use 
additional information regarding resource availability to ad- 
dress the deferred planning decisions and make the associated 
schedu ling decisions as well. 

— . In this paper, we present an integrated approach toplanning 
and scheduling called completable scheduling. We will first 
give an overview of the main ideas behind completable plan- 
ning, and thendiscuss the extension to scheduling. We will 
~~ then discuss how completable schedules are learned through 
an explanation-based learning strategy called contingent 
EBL. Finally, we will briefly discuss the implementation, in- 
cluding some preliminary results and ongoing experiments. 

COMPLETABLE SCHEDULING 

Overview of Completable Planning 

to completable planning [Gervasio90a, Gervasio90b, Gerva- 
•• sio91], a classical planner is augmented with a reactive com- 
ponent which provides it with the ability to defer planning de- 
cisions until execution time. As an augmented classical 
planning approach, completable planning retains the advan- 
tages of classical planning while buying into the advantages 
provided by reactivity. From classical planning, completable 
planning borrows the ability to construct provably-correct 
plans for providing goal-directed behavior. From reactive 
planning, it borrows planning flexibility and the ability to uti- 
lize runtime information in making planning decisions. Com- 
pfetable planning achieves the integration through the achiev- 
ability criterion, which requires every deferred goal to be 
proven achievable. Proving achievability requires proving 
that there exists a plan which will achieve the goal. Our re- 
search has shown that proving the existence of a plan does not 
' *' necessarily entail determining the plan itself, and the intuition 
is that proving achievability requires much simpler and mere 
readily available a priori knowledge than full-blown plan- 
ning. A completable planner is thus able to construct pro- 
vably-correct plans in spite of incomplete a priori informa- 
tion, and in doing so provide goal-directedness to its reactive 
component while allowing itself to defer decisions and utilize 
runtime information in addressing deferred goals. 

Deferring Decisions 

The deferment of scheduling decisions is a powerful tool in 
dealing with imperfect a priori information. The complexity 
of real-world domains makes it difficult to construct perfect 
models. Even when perfect models exist, their use often ex- 
ceeds reasonable computational bounds. A realistic schedul- 



using classical planning techniques on imperfect information. 

First, aschedule may be incomplete due toan unspecifiable 
parameter setting . With the lack of a fine-grained and tracta- 
ble world model, a scheduling system may not be able to de- 
termine precise parameter settings a priori. For example, the 
parameters of an operation may be dependent cm the proper- 
ties of a particular object, which may not be known prior to 


execution, to attaching two parts usingabolt, all thatasystem 
may know is that it will be given a bolt of some size, but it may 
not know precisely what size. However, provided it has ac- 
cess to differently-sized bits and wrenches, it can plan a drill- 
ing operation followed by a bolting operation without speci- 
fying the precise bit and wrench to use. During execution, 
when it is given the bolt, it can then determine the appropriate 
values for bit size and wrench size. Completable scheduling 
allows the use of conjectured variables to act as placeholders 
for unspecified parameter settings provided achievability 
proofs can be constructed for their eventual instantiation. By 
allowing deferred parameter settings, completable schedul- 
ing enables a system to both plan ahead and yet remain flex- 
ible enough to deal with some uncertainty. 

Second, a schedule may be incomplete due to an undeter- 
minable number of iterations. An imperfect world model may 
include incomplete characterizations of operations and their 
effects. Consequently, for an action that requires repetition to 
achieve some goal, the precise number of iterations needed 
may not be determinable prior to execution. For example, the 
depth to which a milling operation cuts through a part is de- 
pendent on the face cutter used. Prior to execution, a system 
may not know whichface cutter will be set up on the machine. 
However, it knows that regardless of which face cutter is used, 
the desired cut can be achieved by simply repeating the mill- 
ing operation as many times as necessary. By not tying itself 
to a particular face cutter and consequently a particular num- 
ber of iterations, during execution the system can choose to 
use the current set-up and save the cost of changing set-ups, 
or it can elect to change to a more efficient set-up. Complet- 
able scheduling permits the deferment of iteration decisions 
provided incremental progress which converges to the goal 
can be proven. Through this deferment, acompletable system 
can use imperfect operation descriptions as well as make opti- 
mizations to a schedule based on runtime information. 

Third, a schedule may be incomplete due to an unidentifi- 
able operation choice or task-machine assignment. This case 
arises when there are multiple ways of achieving the same 
goal from different states and the system lacks the necessary 
a priori information for identifying which particular state will 
be reached. TTus case also arises when there are multipl e ways 
of achieving a goal, with different situations resulting in dif- 
ferent preferences among the various alternatives, and the 
system does notknowapriori which situation will be reached. 
For example, in planning to shape an object, a system might 
use some or all of various cutting operations, such as milling, 
plani ng, sawing, or grinding. Whether there are several possi- 
ble states requiring different operations or multiple applicable 
operations with unknown preferences, a system can use addi- 
tional runtime information to make a more-informed opera- 
tion choice. Completable scheduling allows a system to defer 
operation choice provided it can prove that there exists a way 
to reach the next state regardless of which of the possible 
states is reached. This deferment is useful for two reasons. 
First, it enables a system to use the same schedule to achieve 
a goal from any of several different states. Second, it allows 
a system to apply preferences to a set of possible operations 
using more complete and accurate runtime information. 
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Fourth, a schedule may be incomplete due to an unorder- 
able set of operations. Imperfect a priori information may re- 
sult in insufficient constraints for completely ordering a set of 
operations. For example, in the construction of two parts, the 
only precedence conkraints may be between the milling, 
drilling, and tapping operations for each part — i.e. the opera- 
tions for the different parts can be ordered in any way. De- 
pending upon a priori known factors such as the parts in- 
volved and the difficulty erf changing set-ups as well as a 
priori unknown factors such as the initial set-up and machine 
availability, particular orderings will be more desirable than 
others. By deferring the decision until all the factors are 
known, a system can utilize runtime information to make de- 
cisions for more optimal orderings. Completable scheduling 
permits the deferment of ordering decisions provided the dif- 
ferent orderings are all capable of achieving the goal. In doing 
so, a completable planner can utilize runtime information in 
making more— informed ordering decisions for an uncon- 
strained set of actions. 


Proving Achievability 

While imperfect a priori information is the primary reason for 
deferring decisions, achievability is the primary criterion for 
deferment in completable scheduling. By requiring that a def- 
erred goal be proven achievable, completable scheduling en- 
ables the construction of incomplete yet provably-conect 
plans. Previous woric on achievability involved finding 
proofs for the existence of plans to achieve deferred goals. 
Achievability proofs for deferred parameter settings and 
number of iterations are discussed in [Gervasio90a, Gerva- 
sio90b], and for deferred operator choice in [Gervasio9 1 ]. In 
[Gervasio91], completable planning was also extended to 
probabilistic domains by relaxing the original criterion of ab- 
solute achievability to probable achievability. 

Scheduling domains give rise to further new issues in ach- 
ievability. In planning, die main focus is finding a plan, or se- 
quence of actions, which achieves the goal from a given initial 
state. In scheduling, the existence of several possible sched- 
ules is taken as a given, and the focus is choosing one from 
among them using some set of preference criteria, maximiz- 
ing particular performance measures. Examples of perform- 
ance goals are meeting deadlines and minimizing idle time. 
Thus, simply defining a goal to be achievable if there exists 
aplanforitisinsufficientforscheduling. Achievability must 
also be related to the idea of optimization and relative prefer- 
ences between possible courses of action. For example, prov- 
ing the achievability of the goal associated with an unordered 
set of actions is implicit in the construction of a nonlinear 
plan — i.e. actions are left unordered if there are no constraints 
requiring precedence relations between them. Thus there ex- 
ists a plan for achieving the goal. However, there is the inter- 
esting issue erf deciding on a complete ordering during execu- 
tion. This involves seeking out additional information for 
evaluating the different options as well as carrying out the op- 
erations themselves. In tying the concept of achievability to 
optimization, we can also better investigate a primary motiva- 
tion for combining classical and reactive techniques: the abil- 
ity to utilize runtime information in planning. Goal-directed, 


robust behavior in the face of uncertainty is one reason for 
augmen ting a classical planner with reactive abilities. How- 
ever, another reason to integrate the two approaches , is to take 
advantage of the wealth of information which becomes avail- 
able at runtime. This additional information facilitates plan- 
ning by helping to focus the search for an appropriate action. 

LEARNING COMPLETABLE SCHEDULES 

Explanation-based learning [DeJong86, Mitchell86] has 
been demonstrated to be useful in improving the performance 
of various planning systems [Bennett90, Chien89, Fikes72, 
Hammond86, Mintoo85], and in [Gervasio90a, Gervasio91] 
we present an explanation-based learning strategy called 
contingent EBL for learning completable plans. Learning 
completable schedules basically involves learning to distin- 
guish between a priori planning decisions and decisions 
which have to be made or are better made during execution. 
Learning when to defer decisions involves first identifying 
the deferred decision, then constructing an achievability 
proof for the associated deferred goal. Then a completer for 
making the deferred decision during execution must be incor- 
porated into the learned general plan. 

Identifying Deferred Decisions 

A main difference between classical plans and completable 
plans is the existence of deferred decisions in completable 
plans. In constructing an explanation for how a given training 
example achieves a target goal, an EBL system must explain 
how each action is chosen for execution. In planning, this 
usually means verifying that previous actions achieve the pre- 
conditions necessary for the execution of an action. However, 
with the addition of reactive abilities and the option to utilize 
runtime information, a system needs to distinguish between 
a priori satisfied preconditions and runtime-verified precon- 
ditions. Our solution is to allow the system to distinguish be- 
tween apricri information and runtime-gathered information 
and toprefer a classical proof of correctness to an explanation 
of achievability. Thus, in explaining how an action is chosen 
for execution, a system first attempts to explain its precondi- 
tions with a priori available information. If this is unsucces- 
sful, then the action being explained is tagged as a potential 
deferred decision, and the system attempts to construct an 
achievability explanation for the precondition. Only if it is 
successful isthe learning process allowed tocontinue. Thefi- 
nal explanation will thus contain the identified deferred deci- 
sions as well as their supporting achievability explanations. 

lyingthe concept of achievability tooptimization adds fur- 
ther concerns. An explanation of executability is no longer 
enough. Explanations for preferences may also need to be 
constructed, and as with other deferred decisions, the asso- 
ciated runtime verified conditions need to be distinguished 
from a priori satisfied conditions. As with proofs of correct- 
ness and explanations of achievability, explanations of prefer- 
ences may also be constructed in standard EBL fashion. 

Constructing Achievability Proofs 

To construe* provably-conect plans, a completable planner 
must construct achievability proofs for the deferred goals erf 
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its incomplete plans. While the mechanics of constructing 
proofs of conectness vs. proofs of achievability are essential- 
ly the same — both use standard EBL on a given domain theo- 
ry — there are some requirements needed for a d omain theory 
to be used in proving achievability. 

There are four types of deferred decisions and each requires 
particular kinds of information for proving achievability. 
First, deferred parameter settings must be represented, and 
this is done using conjectured variables. These variables may 
" only be introduced in the context of the rules used to construct 
their corresponding achievability explanations, thus guaran- 
teeing that every conjectured variable in an explanation has 
a supporting achievability proof. Second, a system must be 
able to reason about the incremental progress achieved by a 
repeated action. This requires action characterizations to in- 
clude statements regarding the changes made with respect to 
some measurable quantity. This can then be used to reason 
about progress towards the goal. Third, the incompletely 
known situation requiring a deferred operator choice must be 
represented in such a way that the system can reason about the 
space of possibilities. Achievability can then be measured in 
terms of the coverage provided by the alternative actions over 
this space. Finally, proving achievability with respect to an 
unordered set of operations is implicit in the absence of prece- 
dence constraints between the operations, which means that 
any of the possible total orderings will achieve the goal. 

The second aspect of achievability, optimality, also im- 
poses certain requirements on the domain theory used to con- 
struct explanations. The heuristics to be used in making dis- 
patching or scheduling decisions must be built in to the 
domain theory. These heuristics can then be used both for 
constructing a priori explanations and making runtime deci- 
sions. In explaining particular decisions made in a training 
example, a system can then construct explanations incorpo- 
rating the heuristics and learn general completable plans 
which will employ the heuristics in future applications. 

Incorporating Completors 

The final step in learning how to construct a completable 
schedule is to incorporate completion steps into the learned 
general plan. There are four types of completors correspond- 
ing to the four different types of deferred decision. The first, 
amonitcr, finds avaluetoreplaceaconjectured variable — i.e. 
it determines a specific parameter setting. The second, a re- 
peat loop, repeatedly executes an action until a particular exit 
condition, the deferred goal, is reached. The third, a condi- 
tional, evaluates the current state and determines an appropri- 
ate action based on which conditions are satisfied. F inal ly, the 
fourth, a dispatcher, determines a complete ordering for an 
unordered set of operations, based cm a given set of heuristics. 
The achievability proofs constructed for the deferred deci- 
sions addressed by these completors are incorporated into the 
"explanations supporting the learned plan. Thus the achievab- 
ility conditions guaranteeing the existence of a completion 
are also in the learned plan. Provided these conditions, along 
with other preconditions, are satisfied in future instances, a 
completion is guaranteed to be found for the incomplete plan 
yielded by the learned general plan. 


IMPLEMENTATION 

A simple scheduling domain theory has been constructed to 
compare the performance of acompletable scheduling system 
with that of a purely classical scheduling system as well as a 
purely reactive scheduling system. The domain involves a 
single machine which can be set up in various ways, each set- 
up of which is capable of performing some set of tasks. The 
same task may take different processing times on different 
set-ups. Furthermore, there is a set-up cost involved in 
changing set-ups. A job consists of a partially ordered set of 
tasks, and a scheduling problem involves a set of independent 
jobs. Initially, the only ordering constraints between tasks are 
based on deadlines. However, additional precedence con- 
straints may be imposed between the tasks of a job if the a pri- 
ori planning module of the system determines that one task is 
needed toestablishthe preconditions for another task. Uncer- 
tainty enters into the picture through an unknown initial sta- 
te — Le. the system does not know a priori which set-up will 
be on the machine when it starts executing its plan. Final ly, 
the goodness of a schedule is measured by the length of time 
taken by the system to finish a set of jobs. 

Preliminary results show that a completable system ’s abil- 
ity to adapt to varying initial states enables it to construct more 
efficient plans/schedules than a classical scheduling, which 
commits itself to specific set-ups and complete task orderings 
prior to execution. Furthermore, the completable system 
needs less time both to leam a general completable schedule 
as well as construct a specific completable schedule, although 
it does incur the additional cost of runtime plan completion. 
The completable system is also able to construct more effi- 
cient plans than a reactive system because it is more focused 
in its search for an applicable action, having determined as 
many precedence constraints between tasks as it can prior to 
execution. Although both use the same heuristics for choos- 
ing between multiple applicable actions, the reactive system 
has the additional burden of sorting out precedence relations 
between tasks during execution. Furthermore, although the 
completable system initially needs to construct a completable 
schedule, the use of learning helps reduce the a priori planning 
cost it incurs over the reactive scheduler. We are currently 
running experiments to gather more data about the perform- 
ance of the three approaches given different distributions and 
different machine/set-up/task-processing profiles. The re- 
sults are expected tohelp identify particular domain and prob- 
lem characteristics which favor the different approaches. 

SUMMARY AND CONCLUSIONS 

This work integrates planning — the determination cf an or- 
dered set of tasks — and scheduling — the assignment of those 
tasks to resource — through completable plans. Because com- 
pletable plans are incomplete, additional planning is neces- 
sary during execution, when scheduling has begun todispatch 
the tasks. Thus, this work differs from reactive approaches, 
such as those discussed in [Ow88, Prosser89, Smith90, Zwe- 
ben90] , where planning is separated from scheduling, and the 
main approach to uncertainty in the environment is to replan 
when the constraints of the original plan are violated. While 
replanning is a valuable tod which any real system will even- 



tually need, our work first focuses on constructing plans 
which are as flexible as possible to minimize the need for fail- 
ure recovery. In this sense, it is similar to ideas presented in 
[Dnunmond90, Martin90], Drummond and Bresina present 
an algorithm for maximizing the probability of goal satisfac- 
tion in the case of actions with different possible outcomes, 
which is one of the problems the conditionals in completable 
scheduling address. Martin and Allen also prove the achiev- 
ability of goals deferred to the reactive planner, but they doso 
using empirical methods, in contrast to the explanation-based 
methods we use. Completable scheduling may also be viewed 
as a shallow hierarchical planner, where runtime decisions are 
at the lowest level. However, unlike other hierarchical plan- 
ners and schedulers, such as ABSTRIPS [Sacerdoti74], 
MOLGEN [Stefik81], and ISIS [Fox84], a completable 
scheduling system uses the achievability constraint to guaran- 
tee completability at lower levels. The ordered monotcnic 
hierarchies of ALPINE [Knoblock90] are a similar idea. The 
difference is that ALPINE performs abstraction based on the 
deletion of literals, while in proving achievability complet- 
able scheduling uses explicitly^mare general or abstract 
knowledge regarding the deferred goals and their properties. 

The idea of deferred decisions is not a novel one — the least 
commitment principle is a basic foundation of nonlin earplan- 
ning, for example. What completable scheduling does is ex- 
tend the least commitment principle to execution time and in 
doing so, achieving a well-founded integration of planning 
and scheduling. Unlike other reactive approaches, in which 
all decisions are subject to deferment, in completable sched- 
uling only achievable decisions may be deferred. This has 
two main benefits. The first is that the cost of dynamic deci- 
sion-making is minimized, since only some goals must be 
planned for and scheduled during execution. The second is 
that the robustness and flexibility afforded by reactivity is 
gained without losing the goal-directedness and guarantees 
of success afforded by a priori pl annin g. Additionally, the use 
of contingent EBL enables a completable scheduling system 
to improve its performance through experience. By learning 
general completable schedules from example, the system can 
amortize the cost of constructing a completable schedule over 
the number of times the learned general schedule is applied 
in future instances as well as reduce the planning cost incurred 
by the system’s a priori planning module. 
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Abstract J 

Our research focuses on the problem of recovering from 
perturbations in large-scale schedules, specifically on the 
ability of a human-machine partnership to dynamically 
modify an airline schedule in response to unanticipated 
disruptions. This task is characterized by massive in- 
terdependencies and a large space of possible actions. 
Our approach is to apply both qualitative, knowledge- 
intensive techniques relying on a memory of stereotypi- 
cal failures and appropriate recoveries, and quantitative 
techniques drawn from the Operations Research com- 
munity’s work on scheduling. Our main scientific chal- 
lenge is to represent schedules, failures and repairs so as 
to make both sets of techniques applicable to the same 
data. 

This paper outlines ongoing research in which we are 
cooperating with United Airlines to develop our under- 
standing of the scientific issues underlying the practical- 
ities of dynamic, real-time schedule repair. 

Irregular Operations Scheduling (IOPS) 

Airline schedules are highly complex, structured ob- 
jects, with large numbers of internal interdependen- 
cies. Airlines must confront the consequences of uncer- 
tainty in the execution of their daily schedules — un- 
certainty stemming from inclement weather, sick calls 
from crew members, mechanical problems with aircraft, 
constraints on airport resources, and other problems. A 
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snowstorm at a key airport, for example, can have dev- 
astating consequences on the operations of an airline, ef- 
fects from which it may take days to recover. The inter- 
dependencies among factors like crew scheduling, main- 
tenance routing, and congestion at airports add further 
complication to the daily planning problem. Because 
of these interdependencies, even a single disruption and 
the consequent attempts at recovery typically involve 
widespread and long-lasting downstream effects. The 
search space of possible recoveries to a schedule disrup- 
tion is enormous. 

Airlines employ schedule planners who attempt to 
mitigate the effects of schedule disruptions. Their maun 
goals are to minimize both passenger inconvenience and 
the cost of implementing the repair, while accounting 
for crew work rules, aircraft maintenance schedules, and 
other factors. An additional goal is to minimize the 
overall complexity of a repair. 

Controllers attempt to balance the trade-offs and un- 
certainties of irregular events, typically using informa- 
tion provided by various decision support systems such 
as real-time scheduling displays and passenger booking 
data. However, very few, if any, of these systems provide 
the planner with decision-making advice in the form of 
strategies or specific recommendations to counteract the 
adversity of a particular event. The goal of our research 
is to develop the scientific foundations for a new class of 
decision support tool to address this problem. 

From the viewpoint of Artificial Intelligence planning 
and decision support, the key features of the irregular 
operations planning task are: 

• Airline schedules are large, complex, and highly inter- 
dependent. 

• Solving schedule problems by exhaustive search is 
generally infeasible. 

• Current situations typically share more with past sit- 
uations than they differ from them. 
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• While they may be similar, no two situations are ever 
entirely identical. This means that simply storing and 
reusing a “library* of solutions will not suffice. 

The size of the search space, together with the re- 
curring nature of typical problems, suggests a solution 
based on the re-use of plans. But re-using plans means 
more than just retrieving and replaying old solutions. 
Because the details of situations change over time, the 
system will need to be able to notice that a retrieved 
plan does not exactly fit the current situation, there- 
fore it will need to modify its retrieved plans to fit new 
situations. 

Our approach to plan repair is to provide qualitative 
expertise in the form of a case library linking descrip- 
tions of stereotypical problems with appropriate recov- 
ery strategies, and quantitative expertise in the form 
of optimization techniques drawn from the Operations 
Research (OR) community. The goal of our research is 
to develop the scientific foundations for a new class of 
decision support tool. The IOPS Advisor, currently un- 
der development, couples the experiential knowWge of 
schedulers, which is essential in generating strategies for 
solving a schedule problem, with the quantitative power 
of operations research techniques, which are effective in 
comparing the costs and effectiveness of the potential 
solutions generated by those strategies. Furthermore, 
the quantitative models may be responsible for optimiz- 
ing the details missing from a sketchy solution suggested 
by a qualitative strategy. For example, if a strategy is 
“stop to refuel”, a quantitative analysis may indicate 
where to stop and how much fuel to take on. 

The IOPS Advisor, currently under development, is 
intended to represent schedules, failures, and repairs so 
that both sets of techniques can cooperate using the 
same representational constructs. 

Research Objectives 

The primary scientific focus of this work is on represen- 
tation. Specifically, we are determining how to represent 
schedules, schedule failures, and repair strategies so as 
to enable the IOPS advisor to: 

• Identify and characterize schedule problems so as to 
determine the applicability of prior solutions or spe- 
cific quantitative techniques. 

• Acquire new descriptive features as they become nec- 
essary to discriminate among otherwise indistinguish- 
able situations. 

• Compare the applicability of multiple, competing so- 
lutions to the same problem. 

Knowledge Representation Issues: 

The main knowledge representation issue, and the pri- 
mary focus of our current activity, is to categorize and 
represent the heuristic knowledge used by controllers 
and OR analysts, specifically: 


• How problems are detected and described. 

• What problem-solving strategies exist. 

• What aspects of a problem indicate the applicability 
of one strategy over another. 

In order to gather a realistic set of failures and repairs, 
we have been observing controllers as they detect, diag- 
nose, and repair schedule problems. Our initial study 
has suggested to us that controllers build and use so- 
phisticated, high-level repairs from a small number of 
primitive operators. The primitives form the basic rep- 
resentation vocabulary used to describe actions, and it 
is anticipated that the list will be stable over time. The 
higher-level strategies, on the other hand, axe more dy- 
namic, and one of our tasks is to model the acquisition 
of new high-level strategies. 

Typical primitive operators represent concrete actions 
like: 

• Cancel a segment 

• Delay a segment 

• Divert a flight to a different airport 

• Substitute one aircraft for another 

• Substitute one crew for another 

• Ferry an empty aircraft from one airport to another 

Higher-level strategies, on the other hand, may in- 
volve both primary actions and secondary actions de- 
signed to mitigate the side-effects of the primary actions. 
Or, they might involve a series of steps taken to defer 
the impact of a problem, in the expectation that an op- 
portunistic solution may present itself in the intervening 
time. Other high-level strategies include geographically 
localizing the impact of a problem or, conversely, dilut- 
ing the impact of a problem by spreading a minor delay 
across several geographic points.- 
As we gather more high-level strategies from our ob- 
servation of controllers and from our encoding of quanti- 
tative techniques, our plan is to encapsulate the strate- 
gies in knowledge structures that also include descrip- 
tions of appropriate situations for the strategies. The 
IOPS advisor will extract from the user a description 
of the current situation, propose repair strategies based 
upon the match between the current situation and the 
stored descriptions, and quantitatively evaluate the util- 
ity of situations generated by competing strategies. As 
it performs this selection and comparison, it can acquire, 
from the user, information about features of the world 
that determine the applicability of one strategy over an- 
other. These newly-acquired features cam then become 
part of the selection criteria encoded with the strategies 
in memory. 

Knowledge acquisition 

While the list of primitives is expected to remain rela- 
tively static, an important aspect of the IOPS Advisor 
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is that it will be able to acquire new descriptive features 
as it is used. If the system erroneously suggests a prior 
case as being a good match to the current situation, the 
user can correct this by supplying a descriptive feature 
that would differentiate the current situation from the 
case stored in memory. The error might have occurred 
either because the discriminating feature was not men- 
tioned in the description of the current situation, or be- 
cause it was not mentioned in the stored case. In the 
latter scenario, it can be added. 

In general, a longer-range goal for the IOPS advisor 
is that, in having a human user interact with a plan- 
ning tool, we have an opportunity to record information 
about plan accessing strategies, modification techniques 
and typical failures that can, in turn, become the heuris- 
tics used by a more autonomous system. A system that 
observed human schedulers in action and recorded their 
responses to specific planning problems, and which in- 
dexed those responses in memory using the functional 
criteria discussed above, would become a powerful ex- 
pert assistant — an assistant with a good memory for 
what worked and what didn’t in the past. 

Case-Based Planning Issues 

While case-based planning addresses many of the qual- 
itative problems in the irregular scheduling domain, 
much work must be done before a practical system could 
be put in the hands of a human scheduler. Fortunately, 
the core idea in case-based planning, that of incremen- 
tal modification, is one aspect of the technology that 
could be usefully applied in the near term as a way to 
deal with the type of changes that have to be made to 
schedules during execution. 

One of the recurring problems of automated planning 
is the issue of the repairs that have to be made during ex- 
ecution as a result of unforeseen circumstances. There 
are_ always unexpected problems that arise. Weather, 
crew sickness, and equipment failures cannot be pre- 
dicted. Bottlenecks show up where none was suspected. 
Each of these classes of problems can be recognized using 
a specific set of symptoms, and each requires a specific 
type of repair. 

Run-time repair and optimization, while useful, has 
to be traded-off against the overall stability of an exist- 
ing plan. If a single aircraft is unexpectedly grounded, 
one form of optimization might be to rebuild the en- 
tire system schedule, minus that aircraft. But even if 
such a repair were computationally feasible, implement- 
ing it would be preposterous. A planner that deals with 
unexpected changes in the state of the world by com- 
pletely replanning will be constantly creating new plans 
that will do little more than confuse the people that are 
using them. What is needed instead is incremental, lo- 
cal plan repair, coupled with local optimization. One 
wants to perturb the schedule as little as possible in the 
achievement of an acceptable response to an unexpected 
occurrence. 


Much of the emphasis of CBR research to date has 
been on issues of plan indexing, retrieval and modifi- 
cation. While these issues are clearly present in this 
domain, our emphasis is primarily on plan evaluation 
through objective analytical (OR) tools which are also 
under development. Specifically, we are focusing on how 
to direct the search for relevant cases based on the OR 
model’s assessment of the feasibility or ” utility” of pre- 
viously proposed solutions. Because the two sets of tech- 
niques tend to characterize the problems differently, in- 
tegrating them is a challenge. 

Operations Research Issues 
Operations research analysts tend to think in terms of 
opportunities for optimization. One of our preliminary 
findings is that schedule planners do not readily identify 
these opportunities. Accordingly, an important aspect 
of the integrative research is to identify classes of situ- 
ations in which particular optimization techniques are 
appropriate, and to select descriptive features that al- 
low the system or planners to differentiate among these 
classes. We intend to codify this knowledge in the form 
of cases which couple the relevant optimization tech- 
niques with characteristic features of the appropriate 
class of situation. 

Case Study 

The following hypothetical case study is based on ob- 
servations of airline planners. The case illustrates the 
interplay between qualitative and quantitative reason- 
ing described in this paper. Airports are designated by 
the following three letter codes: SFO = San Francisco, 
EUG = Eugene, and MED = Medford. 

A runway construction project at EUG has imposed 
a weight restriction on departing flights. A depart- 
ing flight EUG-SFO is over the weight limitation by 
approximately 20 passengers. The flight is sched- 
uled to depart on time, however, inbound flow con- 
trol is in effect at SFO (due to fog) and is imposing a 
53 minute pre-takeoff delay on the EUG-SFO flight. 

The planner generates some alternative solutions: 

1. Move the excess passengers to a later EUG-SFO flight. 

2. Have a flight enroute to SFO passing nearby EUG 
stop to pick up the excess passengers. 

3. Remove enough fuel to carry the excess passengers, 
and stop at an intermediate point to refuel. 

At this stage, the alternatives are qualitative: they 
simply match a problem with a strategy. Although in 
many cases this step of the solution process is trivial 
(e.g., weather-related IOP forces cancellations), we be- 
lieve that in general this step is non-trivial and it is 
one aspect of the planner’s job which distinguishes an 
experienced planner from an inexperienced one. 

The next step of the planning process involves evalu- 
ating the relative merits of each proposed strategy with 
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respect to the planner’s goals. In this case the planner 
chose not to solve the problem using strategy (1) be- 
cause pushing the problem to a later flight would most 
likely cause weight restriction problems downline and 
would disservice the excess passengers. Strategy (2) was 
not chosen since it would involve delaying a large num- 
ber of passengers on a different flight to accommodate a 
relatively small number of connecting passengers on the 
EUG-SFO flight. On further analysis of strategy (3), the 
controller determined that, since SFO air traffic control 
had already imposed a 53-minute delay on the inbound 
flight for reasons of airspace crowding, the flight could 
in fact refuel at MED and carry all passengers to SFO as 
planned without incurring additional delays. The cost 
of landing and departing at MED was considered negli- 
gible in comparison to the alternative costs of delaying 
passengers and causing misconnections of aircraft and 
people (although this calculation was not performed ex- 
plicitly). 

Notice that the planner’s analysis in choosing among 
alternatives remains highly qualitative. The planner 
uses various sources of information to determine the vi- 
ability of each approach, however, he rarely explicitly 
calculates the cost impact of various strategies. We be- 
lieve that at this stage the planner could be greatly aided 
by OR models which: 

• provide an objective analysis of the relative merits of 
each strategy based on utility measures. 

• determine optimal implementations of high-level 
strategies, for example, given strategy (2), choosing 
an appropriate flight, or, given strategy (3), choosing 
an appropriate airport. 

Anticipated Results 

Our key preliminary result is a growing catalogue of 
stereotypical problems and appropriate repair strate- 
gies, which form the backbone of a domain theory of 
schedule failure repair. We anticipate that a longer- 
term result of our research will be a working prototype 
of the IOPS Advisor System, This prototype will em- 
body the failure descriptions and recovery strategies, as 
well as a set of features characterizing appropriate situ- 
ations in which to apply specific quantitative optimiza- 
tion tools. The knowledge-based system will suggest 
strategies, given a description of the problem, while the 
OR components will be responsible for evaluating the 
costs and benefits of the proposed strategies and for de- 
termining specific implementations of the strategies. 

Evaluation 

The bases against which we can evaluate the IOPS ad- 
visor project are: 

• Does the system enable a controller to produce good 
schedule repairs? In particular, can a controller use 
the system’s prepackaged strategies and OR evalu- 


ation methods to improve upon solutions produced 
using the controller’s own judgment? 

• How good are the high-level strategies that the ex- 
perienced planners employ? How often do controllers 
choose the best strategy? While the strategies obvi- 
ously work, are they applied inappropriately? Does 
post-facto analysis repeatedly indicate that some 
other strategy might have been preferable? 

♦ Are individuals able to make use of the canned strate- 
gies? Can one individual recognize and re-use canned 
strategies? Is there any transfer across individuals, 
such that one individual can use strategies developed 
by another? If so, how should the strategies be pre- 
sented to the user? 

• Can novices use the strategies and optimizations from 
the IOPS advisor to generate expert-like repairs? In 
general, how do solutions built by novices differ from 
solutions built by experts? Does the availability of a 
library of expert solutions improve a novice’s perfor- 
mance? 

# Does the integrative AI/OR approach provide a bet- 
ter method than either technique applied alone? Is it 
even possible to model the IOPS problem using either 
technique alone? What form would these models take 
(e.g. large scale linear programming, expert-system)? 
How would each of these approaches compare to the 
integrative approach? 

Summary 

The airline irregular operation problem is representa- 
tive of a general class of scheduling problems. An ideal 
solution would embody both the best quantitative tech- 
niques and the genuine expertise of skilled, experienced 
controllers. Traditionally, the two classes of solution 
have been described in such divergent terms as to make 
integration, or even comparison, difficult. By building 
a uniform representation of schedules, failures and re- 
pairs, our intention is to provide a framework for ex- 
perimenting with qualitative and quantitative solutions 
and, ultimately, for integrating the two. 
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Introduction 

One of the most promising general approaches for solv- 
ing combinatorial search problems is to generate an 
initial, suboptimal solution and then to apply local 
repair heuristics. Techniques based on this approach 
have met with empirical success on many combina- 
torial problems, including the traveling salesman and 
graph partitioning problems[10]. Such techniques also 
have a long tradition in AI, most notably in problem- 
solving systems that operate by debugging initial so- 
lutions [18, 20]. In this paper, we describe how this 
idea can be extended to constraint satisfaction prob- 
lems (CSPs) in a natural manner (see also [14] for full 
paper). 

Most of the previous work on CSP algorithms has 
assumed a standard backtracking approach in which 
a partial assignment to the variables is incrementally 
extended. In contrast, our method starts with a com- 
plete, but inconsistent assignment and then incremen- 
tally repairs constraint violations until a consistent 
assignment is achieved. The method is guided by a 
simple ordering heuristic for repairing constraint vio- 
lations: identify a variable that is currently in conflict 
and select a new value that minimizes the number of 
outstanding constraint violations. 

We present empirical evidence showing that on some 
standard problems our approach is considerably more 
efficient than traditional backtracking methods. For 
exwnple, on the n-queens problem, our method quickly 
finds solutions to the one million queens problem[l5]. 
We argue that the reason that repair-based methods 
can outperform backtracking methods is because a 
complete assignment can be more informative in guid- 
ing search than a partial assignment. However, the 
utility of the extra information is domain dependent. 

The work described in this paper was inspired by 
a surprisingly effective neural network developed by 
Adorf and Johnston [1] for scheduling astronomical ob- 
servations on the Hubble Space Telescope. Our heuris- 
tic CSP method was distilled from an analysis of the 
network. In the process of carrying out the analysis, 
we discovered that the effectiveness of the network has 
little to do with its connectionist implementation. Fur- 


thermore, the ideas employed in the network can be 
implemented very efficiently within a symbolic CSP 
framework. The symbolic implementation is extremely 
simple. It also has the advantage that several different 
search strategies can be employed, although we have 
found that hill-climbing methods are particularly well- 
suited for the applications that we have investigated. 

We begin the paper with a brief review of Adorf and 
Johnston’s neural network. Following this, we describe 
our symbolic method for heuristic repair. _ t 

* - - 1 : • . 

Previous Works The GDS Network 

By alrnost any measure, the Hubble Space Telescope 
scheduling problem is a complex task [11, 17]. Be- 
tween ten thousand and thirty thousand astronomi- 
cal observations per year must be scheduled, subject 
to a great variety of constraints including power re- 
strictions, observation priorities, time-dependent or- 
bital characteristics, movement of astronomical bod- 
ies, stray light sources, etc. Because the telescope 
is an extremely valuable resource with a limited life- 
time, efficient scheduling is a critical concern. An ini- 
tial scheduling system, developed using traditional pro- 
gramming methods, highlighted the difficulty of the 
problem; it was estimated that it would take over three 
weeks for the system to schedule one week of observa- 
tions. This problem was remedied by the development 
of a successful constraint-based system to augment the 
initial system. At the heart of the constraint-based sys- 
tem is a neural network developed by Adorf and John- 
ston, the Guarded Discrete Stochastic (GDS) network, 
which searches for a schedule [1]. 

From a computational point of view, the network is 
interesting because Adorf and Johnston found that it 
performs well on a variety of tasks, in addition to the 
space telescope scheduling problem. For example, the 
network performed significantly better on the n-queens 
problem than methods that had been previously devel- 
oped. The n-queens problem requires placing n queens 
on an n x n chessboard so that no two queens share a 
row, column or diagonal. The network has been used 
to solve problems of up to 1024 queens, whereas most 
heuristic backtracking methods encounter difficulties 
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with problems one-tenth that size[19]. 

The GDS network is a modified Hopfield network[8]. 
In a standard Hopfield network, all connections be- 
tween neurons are symmetric. In the GDS network, the 
main network is coupled asymmetrically to an auxiliary 
network of guard neurons which restricts the configu- 
rations that the network can assume. This modifica- 
tion enables the network to rapidly find a solution for 
many problems, even when it is simulated on a serial 
machine. Unfortunately, convergence to a stable con- 
figuration is no longer guaranteed. Thus the network 
can fall into a local minimum involving a group of un- 
stable states among which it will oscillate. In practice, 
however, if the network fails to converge after some 
number of neuron state transitions, it can simply be 
stopped and started over. 

To solve the n-queens problem with the GDS net- 
work, each of the n x n board positions is represented 
by a neuron whose output is either one or zero depend- 
ing on whether or not a queen is located in that posi- 
tion. (Note that this is a local representation rather 
than a distributed representation of the board.) If 
two board positions are inconsistent, then an inhibit- 
ing connection exists between the corresponding two 
neurons. For example, all the neurons in a column will 
inhibit each other, representing the constraint that two 
queens cannot be in the same column. For each row, 
a guard neuron is connected to each of the neurons in 
the row and gives the neurons in that row a large exci- 
tatory input, large enough so that at least one neuron 
in the row will turn on. Thus, the guard neurons en- 
force the constraint that one queen in each row must be 
on. The network is updated on each cycle by randomly 
picking a row and flipping the state of the neuron in 
that row whose input is most inconsistent with its cur- 
rent output. A solution is realized when the output of 
every neuron is consistent with its input. 

Why does the GDS Net Perform So Well? 

Our analysis of the GDS network was motivated by 
the question: “Why does the network perform so much 
better than traditional backtracking methods on cer- 
tain tasks?” In particular, we were intrigued by the 
results on the n-queens problem, since this problem 
has received considerable attention from previous re- 
searchers. For n-queens, Adorf and Johnston found 
empirically that the network requires a linear number 
of transitions to converge. Since each transition re- 
quires linear time, the expected (empirical) time for 
the network to find a solution is 0(n 2 ). To check this 
behavior, Johnston and Adorf ran experiments with n 
as high as 1024, at which point memory limitations 
became a problem. 1 

1 The network, which is programmed in Lisp, requires 

approximately 11 minutes to solve the 1024 queens prob- 
lem on & TI Explorer II. For larger problems, memory be- 
comes a limiting factor because the the network requires 
approximately 0(n 2 ) space. 


Nonsystematic Search Hypothesis 

Initially, we hypothesized that it was the nonsystem- 
atic nature of the network’s search that allowed it to 
perform much better than systematic depth-first back- 
tracking search. There are two potential problems 
associated with systematic depth-first search. First, 
the search space may be organized in such a way 
that poorer choices are explored first at each branch 
point. For instance, in the n-queens problem, depth- 
first search tends to find a solution much more quickly 
when the first queen is placed in the center of the first 
row rather than the corner. It would appear that solu- 
tion density is much greater in the former case[19], but 
most naive algorithms tend to start in the corner sim- 
ply because humans find it more natural to program 
that way. However, the fact that a systematic algo- 
rithm may consistantly make poor choices does not 
completely explain why the GDS network performs so 
well for n-queens. A backtracking program that ran- 
domly orders rows (and columns within rows) performs 
much better than the naive method, and yet still per- 
forms poorly relative to the GDS network. 

The second potential problem with depth-first search 
is more significant and more subtle. Depth-first search 
can be a disadvantage when solutions are not evenly 
distributed throughout the search space. As the distri- 
bution of solutions becomes less uniform, and^ there- 
fore, the solutions become more clustered, the time 
to search between solution clusters increases. Thus, 
we conclude that, in a tree where the solutions are 
clustered, depth-first search performs relatively poorly. 
In comparison, a search strategy which examines the 
leaves of the tree in random order is not affected by 
solution clustering. 

We investigated whether this phenomenon explained 
the relatively poor performance of depth-first search on 
n-queens by experimenting with a randomized search 
algorithm, called a Las Vegas algorithm [2]. The al- 
gorithm begins by selecting a path from the root to 
a leaf. To select a path, the algorithm starts at the 
root node and chooses one of its children with equal 
probability. This process continues recursively until a 
leaf is encountered. If the leaf is a solution the al- 
gorithm terminates, if not, it starts over again at the 
root and selects a path. The same path may be exam- 
ined more than once, since no memory is maintained 
between successive trials. 

The Las Vegas algorithm does, in fact, perform bet- 
ter than simple depth-first search on n-queens. In fact, 
this result was already known [2]. However, the perfor- 
mance of the Las Vegas algorithm is still not nearly as 
good as that of the GDS network, and so we concluded 
that the systematicity hypothesis alone cannot explain 
the network’s behavior. 

Informedness Hypothesis 

Our second hypothesis was that the network’s search 
process uses information about the current assignment 
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that is not available to a standard backtracking pro- 
gram. We now believe this hypothesis is correct, in 
that it explains why the network works so well. In par- 
ticular, the key to the network’s performance appears 
to be that state transitions are made so as to reduce the 
number of outstanding inconsistencies in the network; 
specifically, each state transition involves flipping the 
neuron whose output is most inconsistent with its cur- 
rent input. From a constraint satisfaction perspective, 
it is as if the network reassigns a value for a variable by 
choosing the value that violates the fewest constraints. 
This idea is captured by the following heuristic: 
Mln-Conflicts heuristic: 

Given : A set of variables, a set of binary constraints, 
and an assignment specifying a value for each vari- 
able. Two variables conflict if their values violate a 
constraint. 

Procedure: Select a variable that is in conflict, and as- 
sign it a value that minimizes the number of conflicts. 3 * 5 
(Break ties randomly.) 

We have found that the network’s behavior can be 
approximated by a symbolic system that uses the min- 
conflicts heuristic for hill-climbing. The hill-climbing 
system starts with an initial assignment generated in a 
preprocessing phase. 3 At each choice point, the heuris- 
tic chooses a variable that is currently in conflict and 
reassigns its value, until a solution is found. The sys- 
tem thus searches the space of possible assignments, 
favoring assignments with fewer total conflicts. Of 
course, the hill-climbing system can become “stuck” 
in a local maximum, in the same way that the network 
may become “stuck” in a local minimum. 

There are two aspects of the min-conflicts hill- 
climbing method that distinguish it from standard 
backtracking approaches for CSP problems. First, in- 
stead of extending a consistent partial assignment, the 
min-conflicts method repairs a complete but incon- 
sistent assignment by reducing those inconsistencies. 
Thus, to guide its search, it uses information about 
the current assignment that is not available to a stan- 
dard backtracking algorithm. Second, the use of a hill- 
climbing strategy produces a different style of search. 

We have also found that extracting the method from 
the network enables us to tease apart and experiment 
with its different components. In particular, the idea of 
repairing an inconsistent assignment can be used with 
a variety of different search strategies in addition to 
hill-climbing. 

3 In general, the heuristic attempts to minimize the num- 

ber of other variables that will need to be repaired. For 
binary CSPs, this corresponds to minimizing the number 
of conflicting variables. For general CSPs, where a single 
constraint may involve several variables, the exact method 
of counting the number of variables that will need to be 
repaired depends on the particular constraint. The space 
telescope scheduling problem is a general CSP, whereas the 
other tasks described in this paper are binary CSPs. 

5 See [14] for an analysis of how different initial assign- 
ments can affect the repair phase. 


Highlights of Experimental Results 

This section contains highlights from experiments in 
which we evaluate the performance of the min-conflicts 
heuristic on some standard tasks. These experiments 
identify problems on which min-conflicts performs well, 
as well as problems on which it performs poorly. The 
experiments also show the extent to which the min- 
conflicts approach approximates the behavior of the 
GDS network. 

The N- Queens Problem 

• Min-conflicts hill-climbing approximates the GDS 
network for n-queens. 

• For n > 100 min-conflicts hill-climbing has never 
failed to find a solution. 

• For min-confict8, the required number of repairs ap- 
pears to remain constant as n increases, and the time 
to find a solution grows linearly with n. 

• Standard backtracking using the “most-constrained 
first” heuristic quickly grows large: for 100 runs 
when n > 1000 a backtracking program implement- 
ing the heuristic took more than 12 hours to com- 
plete. 

• Min-conflicts hill-climbing solves the million queens 
problem in less than four minutes on a SPARCsta- 
tion I. 

• W-queens is actually quite an easy problem given the 
right method. 

Scheduling Applications: HST 

• Min-conflicts hill-climbing approximates the GDS 
network for HST scheduling. 

• Much of the overhead (particularly the space over- 
head) in the GDS network is eliminated by using the 
min-conflicts method. 

• Because the min-conflicts heuristic is so simple, a 
min-conflicts scheduler for HST was quickly coded 
in C and is extremely efficient. 

• The simplicity of the min-conflicts method makes it 
easy to experiment with modifications to the heuris- 
tic and the search-strategy. 

• Other telescope scheduling problems have started to 
use the min-conflicts scheduler developed for HST. 

Graph Coloring 

• Min-conflicts hill-climbing approximates the GDS 
network for graph coloring. 

• A standard backtracking algorithm employing a 
Brelaz-like[3] heuristic outperforms min-conflicts 
hill-climbing. 

Summary of Experimental Results 

For each of the three tasks we have examined in detail, 
n-queens, HST scheduling and graph 3-colorability, we 
have found that the GDS network’s behavior can be 
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approximated by the min-conflicts hill-climbing algo- 
rithm. To this extent, we have a theory that ex- 
plains the network’s behavior. Obviously, there are 
certain practical advantages to having “extracted” this 
method from the network. First, the method is very 
simple, and so can be programmed extremely effi- 
ciently, especially if done in a task-specific manner. 
Second, the heuristic we have identified, that is, choos- 
ing the repair which minimizes the number of conflicts, 
is very general. It can be used in combination with dif- 
ferent search strategies and task-specific heuristics, an 
important factor for most practical applications. 

Insofar as the power of our approach is concerned, 
our experimental results are encouraging. We have 
identified two tasks, n- queens and HST scheduling, 
which appear more amenable to our repair-based ap- 
proach than a traditional approach that incrementally 
extends a partial assignment. This is not to say that 
a repair-based approach will do better than any tra- 
ditional approach for solving these tasks, but merely 
that our simple, repair-based method has done rela- 
tively well in comparison to the standard traditional 
methods. We also note that repair-based methods have 
a special advantage for scheduling tasks: they can eas- 
ily be used for both overconstrained and rescheduling 
problems. Thus it seems likely that there are other 
applications for which our approach will prove useful. 

Discussion 

The heuristic method described in this paper can be 
characterized as a local search method[10], in that each 
repair minimizes the number of conflicts for an indi- 
vidual variable. Local search methods have been ap- 
plied to a variety of important problems, often with 
impressive results. For example, the Kernighan-Lin 
method, perhaps the most successful algorithm for 
solving graph-partitioning problems, repeatedly im- 
proves a partitioning by swapping the two vertices 
that yield the greatest cost differential. The much- 
publicized simulated annealing method can also be 
characterized as a form of local search[9]. However, 
it is well-known that the effectiveness of local search 
methods depends greatly on the particular task. 

In fact, it is easy to imagine problems on which 
the min-conflicts heuristic will fail. The heuristic is 
poorly suited for problems with a few highly critical 
constraints and a large number of less important con- 
straints. For example, consider the problem of con- 
structing a four-yew course schedule for a university 
student. We may have an initial schedule which satis- 
fies almost all of the constraints, except that a course 
scheduled for the first year is not actually offered that 
year. If this course is a prerequisite for subsequent 
courses, then many significant changes to the sched- 
ule may be required before it is fixed. In general, if 
repairing a constraint violation requires completely re- 
vising the current assignment, then the min-conflicts 
heuristic will offer little guidance. 


The problems investigated in this paper, especially 
the HST and n-queens problem, tend to be relatively 
uniform in that critical constraints rarely occur. In 
part, this is due to the way the problems are repre- 
sented. For example, in the HST problem, as described 
earlier, the transitive closure of temporal constraints 
is explicitly represented. Thus, a single “after” rela- 
tion can be transformed into a set of “after” relations. 
This improves performance because the min-conflicts 
heuristic is less likely to violate a set of constraints 
than a single constraint. In some cases, we expect 
that more sophisticated techniques will be necessary 
to identify critical constraints [5]. To this end, we are 
currently evaluating explanation-based learning tech- 
niques [4, 13] as a method for identifying critical con- 
straints. r 

The algorithms described in this paper also have an 
important relation to previous work in AI. In partic- 
ular, there is a long history of AI programs that use 
repair or debugging strategies to solve problems, pri- 
marily in the areas of planning and design[18, 20]. This 
approach has recently had a renaissance with the emer- 
gence of case-based[6] and analogical [12, 21] problem 
solving. To solve a problem, a case-based system will 
retrieve the solution from a previous, similar problem 
and repair the old solution so that it solves the new 
problem. 

The fact that the min-conflicts approach per- 
forms well on n- queens, a well-studied, “standard” 
constraint-satisfaction problem, suggests that AI 
repair-based approaches may be more generally use- 
ful than previously thought. However, in some cases it 
can be more time-conBuming to repair a solution than 
to construct a new one from scratch. 

There are many possible extensions to the work re- 
ported here, but three are particularly worth mention- 
ing. First, we expect that there are other applications 
for which the min-conflicts approach will prove useful. 
Conjunctive matching, for example, is an area where 
preliminary results appear promising. This is particu- 
larly true for matching problems that require only that 
a good partial-match be computed. Second, we ex- 
pect that there are interesting ways in which the min- 
conflicts heuristic could be combined with other heuris- 
tics. Finally, there is the possibility of employing the 
min-conflicts heuristic with other search techniques. In 
this paper, we considered only one very basic method, 
hill climbing. However, since the number of conflicts 
in an assignment can serve as a heuristic evaluation 
function, more sophisticated techniques such as best- 
first search are possible candidates for investigation. 
Another possibility is Tabu search [7], a hill-climbing 
technique that maintains a list of forbidden moves in 
order to avoid cycles. Morris[16] has also proposed a 
hill-climbing method which can break out of local max- 
ima by systematically altering the cost function. The 
work by Morris and much of the work on Tabu search 
bears a close relation to our approach. 
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Conclusions 

In this paper we have analyzed a very successful neural 
network algorithm and shown that an extremely sim- 
ple, heuristic search method behaves similarly. Based 
on our experience with both the GDS network and 
min-conflicts hill-climbing, we conclude that the min- 
conflicts heuristic captures the critical aspects of the 
GDS network. In this sense, we have explained why 
the network is so effective. Additionally, by isolating 
the min-conflicts heuristic from the search strategy, we 
distinguished the idea of a repair-based CSP method 
from the particular strategy employed to search within 
the space of repairs. 

Finally, there are several practical implications of 
this work. First, the scheduling system for the Hub- 
ble Space Telescope, SPIKE, now employs our sym- 
bolic method, rather than the network, reducing the 
overhead necessary to arrive at a schedule. Second, 
and perhaps more importantly, it is easy to experiment 
with variations of the symbolic method, which should 
facilitate transferring SPIKE to other scheduling ap- 
plications. Third, by demonstrating that repair-based 
methods are applicable to standard constraint satisfac- 
tion problems, such as ^T-queens, we have provided a 
new tool for solving CSP problems. 
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Abstract 

A system is described which has been built to com- 
pile weekly rotas for the anaesthetists in a large hospi- 
tal. The rota compilation problem is an optimization 
problem (the number of tasks which cannot be assigned 
to an anaesthetist must be minimized ) and has been 
formulated as a constraint satisfaction problem. 

The forward checking algorithm is used to find a 
feasible rota, but because of the size of the problem, it 
cannot find an optimal (or even a good enough) so- 
lution in an acceptable time. Instead , an algorithm 
has been devised which makes local improvements to a 
feasible solution. The algorithm makes use of the con- 
straints as expressed in the CSP to ensure that feasibil- 
ity is maintained, and produces very good rotas which 
are being used by the hospital involved in the project. 

It is argued that formulation as a constraint sat- 
isfaction problem may be a good approach to solving 
discrete optimization problems, even if the resulting 
CSP is too large to be solved exactly in an acceptable 
time. A CSP algorithm may be able to produce a feasi- 
ble solution which can then be improved , giving a good , 
if not provably optimal, solution. 


The Rostering Problem 

Leeds General Infirmary (L.G.I.l is a large teaching 
hospital in the centre of Leeds. Tne anaesthetics de- 
partment consists of 19 consultant anaesthetists and 
24 other full-time anaesthetists in more junior grades, 
who are referred to collectively as junior anaesthetists. 
The junior grades are primarily training grades, and 
part of the junior anaesthetists 9 training is to work 
alongside a consultant anaesthetist. However, in the 
U.K., junior anaesthetists also do some work on their 
own. At the L.G.I., there is a set of operating lists, 
referred to as junior lists, which are always covered 
by junior anaesthetists working on their own. Junior 
anaesthetists may also be required to cover consul- 
tant lists on their own if the consultant is away. The 
consultants work the same pattern of operating lists 
every week, but a weekly rota is required for the ju- 
niors, showing what each will be doing in each of ten 
weekly sessions (Monday to Friday, a.m. and p.m.). 


Department of Anaesthetics 
The General Infirmary at Leeds 
Great George Street 
Leeds LSI 3EX, U.K, 

There are three grades of junior anaesthetist: Se- 
nior Registrar fSR), Registrar and Senior House Offi- 
cer (SHO), in aescending order of seniority. The SRs 
and half the Registrars are assigned for a month or 
more at a time to a training block, which is a spe- 
cialty such as paediatrics, in order to improve their 
skills in that area. Most of the SRs work to a fixed 
timetable in their own specialty for most or all of the 
week, assisting a consultant. The Registrars who are 
on a training block should also work with the consul- 
tant in their training specialty for much of the week, 
although they do not have a fixed training timetable. 
The remaining Registrars are assigned to General Du- 
ties, and are available to cover junior lists, stand in for 
absent consultants and so on, for most of the week, as 
are the training block Registrars when not involved in 
training. The SHOs are not assigned to a particular 
specialty, but are doing general training in the spe- 
cialties not covered by the training blocks; the least 
experienced SHOs should spend most of their time 
accompanying a consultant, while those with more ex- 
perience can ao some of the junior lists on their own, 
or stand in for an absent consultant. 

One of the SRs is assigned to the ‘General Du- 
ties/Admin 9 block, and the administrative part of this 
is to compile the weekly rota. The Admin SR spends 
half a day a week compiling the rota for the following 
week. Since each SR spends a maximum of six months 
on this block, the Admin SR is only becoming expert 
at compiling the rota by the time that the next person 
takes over. The job therefore takes much more time 
than it would if the same person did it all the time; it is 
also difficult to ensure consistency. On the other hand, 
the person compiling the rota needs to be an experi- 
enced anaesthetist, in order to know what specialties 
different people can cope with on their own, and so 
on. The Admin SR is also responsible for making any 
adjustments to the rota after it has been compiled, 
for instance if someone is ill, and needs to be able to 
judge whether a particular operating list will be rela- 
tively straightforward, or requires someone with con- 
siderable experience in the specialty. Hence it is not 
appropriate to entrust the compilation of the rota to 
a clerk, but it was felt that a system which could pro- 
duce the initial rota automatically, under the control 
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of the Admin SR, would be of great benefit. It would 
also allow more strategic questions to be explored, for 
inst«mce, how many anaesthetists of each grade are 
required to cover the operating workload. 

The rota varies from week to week, partly because 
. of the on-call rota. This is compiled separately, for a 
month at a time, and shows for each night of the week, 
and the weekend, five junior anaesthetists who are on 
call to deal with emergency work, for instance in ob- 
stetrics or the Intensive Care Unit. For Registrars and 
SHOs, being on call at night governs what they do on 
the immediately previous and following days. The rota 
also varies because of staff absences, which result in 
changes to the work that needs to be allocated in the 
week. If an SR is away, in many cases the work that he 
or she would have done has to be assigned to someone 
else, preferably to the Registrar working in the same 
specialty, if there is one. If a consultant is absent, 
sometimes no action need be taken, for instance if an 
SR would normally assist the consultant, and can take 
responsibility for the list instead. Often, however, aju- 
a nior anaesthetist who is capable of doing the list alone 
must be found. When junior anaesthetists are absent, 
the work to be done has to be shared amongst fewer 
people; in some weeks the level of absences means that 
several operating lists have to be cancelled. Compiling 
the rota therefore means solving a different problem 
each week: the work to be done varies ^From week to 
week, as do the personnel available to do it. 

If the opportunities for Registrar and SHO training 
are included, it is not possible to compile a weekly rota 
which covers all the work, and the Admin SR tries to 
strike a balance between covering as many operating 
lists as possible and allowing adequate training. The 
first priority, however, is to cover those lists where the 
consultant is absent; the junior lists can, if necessary, 
be left uncovered, in which case the list is cancelled, 
and it is not essential that juniors should be assigned 
to all the training lists available. 

Compiling the Rota 

The first step in compiling the rota for a given 
week (whether manually or by computer) is to record 
the planned absences of each junior anaesthetist and 
their predetermined assignments, i.e. those due to reg- 
ular commitments or to the on-call rota. This gives 
a partly completed rota, the gaps showing where the 
jumors are still available to do the remaining work. 
The Admin SR then needs to know which other oper- 
ating list 8 need to be covered and which training lists 
are available in that week, given the planned absences 
of both consultants and juniors. This gives a set of 
tasks to be done in each session of the week, together 
with a set of people available to do them. In addition, 
some anaesth etis ts must be assigned an half day off 
during the week: normally, an afternoon off is taken 
following a night on call, but if an anaesthetist is not 
Gfi call during the week, an afternoon off has still to be 
aligned. A half day for the compilation of the next 
rota must ako be set aside for the Admin SR. 

The rota compilation system extracts the set of 


tasks to be done, and the junior anaesthetkts avail- 
able, from its basic information about the department, 
which does not change from week to week, and from 
data on absences and the on-call rota, which does need 
to be input each week. The departmental data in- 
cludes, for each consultant operating list, the action 
to be taken if the consultant is away: various strate- 
gies are available, for instance, to assign a specific ju- 
nior anaesthetkt if they are available, and failing that 
one of the different grades of junior, listed in order of 
preference. 

Compiling the rota then consists of assigning an 
anaesthetkt to each task, taking into account the re- 
quirements of the different tasks, e.g. some operating 
lists require a particular grade of anaesthetist, some 
training lkts are only appropriate for the anaesthetist 
training in that specialty, and so on. At the same 
time, the additional afternoons off must be assigned. 
The rota must be optimized, in the sense that the 
number of tasks left unassigned must be minimized, 
while a satisfactory balance is kept between training 
and covering the junior lists. 

The number of tasks to be done varies from week 
to week, but k normally about 90-100, and the num- 
ber of anaesthetkts who can do each task averages 
about 5.5. The number of anaesthetists who need to 
be given a half day off k about 4 or 5. The size of the 
problem can be reduced if we recognize that some of 
the training lists, i.e. the general training lists which 
are principally for SHOs, rather than the specialized 
training lists attached to the training blocks, are of 
much lower priority than other tasks. Acceptable ro- 
tas can be compiled by assigning the other tasks first, 
and then fitting the general training lkts into the re- 
maining gaps. Thk reduces rota compilation to two 
separate problems, the second of which is trivial. The 
first problem then has about 75 tasks to be assigned. 

Constraint Satisfaction Problems 

The constraint satisfaction problem has been dis- 
cussed extensively in the Artificial Intelligence litera- 
ture [see references]; it can be used as a formulation of 
many problems arising in OR. In a constraint satisfac- 
tion problem there are a number of variables, each of 
which has a dkcrete set of possible values (its domain). 
There are ako a number of constraint relations, speci- 
fying which values are mutually compatible for various 
subsets of the variables: for instance, the assignment 
of an anaesthetkt to a task k incompatible with the 
assignment of the same anaesthetkt to another task 
in the same session. A solution to the constraint sat- 
isfaction problem is an assignment of values to the 
variables which satkfies the constraints. 

Although the definition of the CSP does not distin- 
guish between solutions, so that all assignments which 
satisfy the constraints are equally acceptable, it k pos- 
sible to represent optimization problems as CSPs. The 
objective k represented as an additional constraint, 
which changes each time a new solution k found. For 
instance, in a minimization problem, the constraint 
k that the value of the objective must be less that its 
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value in the best solution found so far (or, initially, less 
than some very large number). This ensures that each 
solution is better than the previous one, and when all 
the solutions to the CSP have been found, the last one 
will be optimal. A similar scheme for representing dis- 
crete optimization problems as CSPs is described by 
van Hentenryck [3]. 

In general, constraint satisfaction problems are NP- 
complete, so that although several algorithms exist for 
solving them ([2], [4]), they are not guaranteed to find 
a solution in a reasonable time unless the problem 
is small or has special structure. However, in many 
cases there is a good chance of finding a feasible as- 
signment quite quickly. Optimization problems, on 
the other hand, will almost certainly suffer from the 
exponential worst-case performance, since the search 
cannot be t erminated when the first feasible solution 
is found. Despite this difficulty, it may still be possi- 
ble use a constraint satisfaction formulation as a basis 
for finding good solutions to optimization problems, 
as demonstrated below. 

Nadel [4] surveys the available algorithms for the 
CSP, and compares their performance on some stan- 
dard problems. One of the best algorithms in these ex- 
eriments is the forward checking algorithm, described 
y Haralick and Elliott [2], and this algorithm is used 
by the rota compilation system. 

The Rota Compilation Problem as a CSP 

As mentioned earlier, the first stage in compiling 
the rota is to record the predetermined assignments 
and the planned absences for the week. The CSP for- 
mulation will only be concerned with the problem of 
assigning the remaining tasks to those anaesthetists 
who are still available after this first stage. 

The variables of the CSP are used to represent the 
tasks to be assigned in the given week, and the domain 
of each variable is the set of anaesthetists who can do 
that task. In addition, there is a small number of vari- 
ables which represent a half day off for an individual 
anaesthetist. The domain of such a variable is the list 
of sessions in which the anaesthetist could take a half 
day off. 

The domain of each task variable is arranged in pri- 
ority order, with the best choice of junior anaesthetist 
for the task appearing first. The forward checking al- 
gorithm selects values from the domain in the order 
in which they appear, and hence the anaesthetist ap- 
pearing first in the list is the one most likely to be 
assigned, if available. Although ordering the domains 
is not guaranteed to give the overall best allocation of 
anaesthetists to tasks, it does in practice give accept- 
able results, 

In order to express the relative priorities of the dif- 
ferent types of task, they are divided into three cate- 
gories: essential, preference and optional. The essen- 
tial tasks are those arising from consultant absences; 
an anaesthetist must be assigned to each of these in 
order to achieve a feasible solution. (It is extremely 
unlikely that a situation could arise in practice where 
consultant absences could not be covered.) 


The preference tasks correspond to th e jun ior lists 
and the Registrar accompanied lists, Le. those training 
lists which allow a Registrar to accompany a consul- 
tant anaesthetist in their assigned specialty. To allow 
the algorithm to leave the pref erence ta sks uncovered 
if necessary, an extra value, NONlS, is added as the 
final element in the domain of each of the correspond- 
ing variables. When this variable is considered by the 
algorithm, this value can be selected, if all the anaes- 
thetists who could do this task have been assigned to 
something else. m " 

It has been found that a satisfactory balance be- 
tween covering the junior lists and assigning the Reg- 
istrars to training lists in their own specialty can be 
achieved by covering as many of the preference tasks as 
possible, i.e. the number of preference tasks assigned 
the value N ONE should be minimized. This can be 
done by using an additional constraint to represent 
this objective, as described in section 3. 

The final category is the optional tasks: these are 
the training l ists f or the SHOs, in w hich they accom- 
pany a consultant. These also have the value NONE 
as the last element of their domain. SHOs can be 
assigned to these tasks if there is nothing of higher 
priority which they could do instead^ to reflect this, 
the optional tasks are assigned only after a satisfac- 
tory assignment of the essential and preference tasks 
has been found. The current state of the rota is then 
fixed and the optional tasks are assigned to those ju- 
nior anaesthetists who have not so far been allocated 
to do anything in that session. 

The constraints of the CSP firstly arise from the 
fact that an anaesthetist cannot do two things at once, 
so cannot be assigned to two task variables in the Shine 
session, or to have a half day off at the same time 
as doing a task. These constraints may be thought 
of as general rostering constraints; similar constraints 
expressing the fact that no-one can be assigned to do 
two tasks at the same time will occur in any rota com- 
pilation problem. The anaesthetists’ system also has 
a constraint representing the objective, as already de- 
scribed. 

In addition, there are other constraints reflecting 
particular rostering rules used at the L.G.I., which 
have in fact changed several times during the course of 
the project. Currently, for instance, there is a rule that 
Registrars who are on a training block can be taken 
off training, and assigned to a junior list instead, at 
most once during the week. Constraints of this kind 
are likely to vary from hospital to hospital and, as 
experience at the L.G.I. has shown, to change over 
time. The system has therefore been designed in such 
a way that constraints are easy to express. 

Improving a Feasible Solution 

Having set up the variables and their domains, the 
forward checking algorithm is used to find an assign- 
ment of the essential and pr eference ta sks and the half- 
day variables. Very little backtracking is required to 
find a feasible assignment, because most variables do 
not represent essential tasks and so can if necessary 
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be assigned the value NONE, which, at this stage, 
does not conflict with any other assignment. The al- 
gorithm therefore finds a first feasible solution very 
quickly. However, because of the size of the problem, 
finding the optimum solution would take a very long 
time. Often, finding any improvement to the first so- 
lution takes far longer than would be acceptable. 

It is possible that improvements in the way that 
the forward checking algorithm is used might achieve a 
sufficient increase in speed to allow an optimal solution 
to be found. For instance, there are variable and value 
ordering heuristics, such as those discussed by Nudel 
[5] whicn can be expected to give significant improve- 
ments in appropriate cases. Value ordering heuristics 
cannot be used in this case because the original order- 
ing of the domains must be preserved, and the vari- 
ables with smallest domains cannot be assigned first, 
as is commonly advised, because they do not represent 
tasks which are hard to assign, but rather the Regis- 
trar training lists, which should not be given higher 
priority than other tasks. It is still conceivable that 
variable ordering rules based on problem knowledge 
could be developed. However, rather than pursuing 
this possibility, we have used the forward checking al- 
gorithm only to produce a feasible solution, and looked 
for ways of improving such a solution. This approach 

E roduces good results very quickly, and it seems un- 
kely that an improved forward checking algorithm 
would be able to do any better. 

In order to improve on the best solution that the 
forward checking algorithm can find quickly, an algo- 
rithm has been devised that considers each uncovered 
task in turn and looks for reassignments of related 
tasks which will allow it to be covered. This local 
improvement algorithm was developed through exam- 
ining feasible but non-optimal rotas, and looking for 
reassignments that would improve them. 

Suppose that there is an uncovered task that we 
want to try to find an assignment for. This is a vari- 
able which has been assigned the value NONE. All the 
anaesthetists in the variable’s original domain must 
have been assigned to do something else in this ses- 
sion (otherwise the assignment of NONE would not 
have been made) but it may be possible to free one of 
these anaesthetists by reassigning the task that they 
are currently assigned to (a swapY or by moving a half 
day off from this session to another session (a move). 
The following example (adapted from an actual 
rotal shows the kind of swaps within a session that 
can be made in order to improve the solution. 

Original Domain Assigned 

(R-4 IU6 R-5 SHO-1 R-4 
SHO-2 NONE) 

(R-4 R-6 R-5 SHO-1 R-6 
SHO-2 NONE) 

(R-5 R-4 R-6 NONE) R-5 
(R-5 NONE) NONE 

(R-4 R-6 R-5 NONE) NONE 

iiown in the order in which the 


Variable 

ORTHO-TRAUMA- 

THU-AM 

CW-H-THU-AM 

OBS-THU-AM 

GARDNER-THU-AM 

PSU-I/A-THU-AM 


The variables are 


forward checking algorithm considers them, so that 
the value assigned is the first remaining value in the 
domain. (Values assigned to other variables represent- 
ing tasks in this session have been omitted.) The two 
uncovered operating lists in this Thursday morning 
session (GARDNER and PSU-I/A) can be covered by 
making use of SHO-1 and SHO-2 who are so far unas- 
signed in this session. The simpler swap is to assign 
the ORTHO-TRAUMA list to SHO-1, thus allowing 
R-4 to do the PSU-I/A list. Covering the GARDNER 
list entails a chain of two exchanges: SHO-2 takes the 
CW-II list, R-6 takes the OBS Ust, and R-5 can then 
do the GARDNER list. 

A simple example of a move is to move an anaes- 
thetist’s half day off from a session where there is an 
uncovered task that this anaesthetist could do to an- 
other session where they have not been assigned to do 
anything. More complicated changes involve a Bwap, 
of the kind illustrated above, combined with a move. 
This is done if moving a half day off would allow an un- 
covered task to be done by the anaesthetist concerned, 
and the swap has to be done to free the anaesthetist 
in the session that the half day off is being moved to. 

The local improvement algorithm considers each 
uncovered task in turn in the current solution, and 
for each anaesthetist in the original domain of the 
corresponding variable, each of the above changes is 
tried, starting with the simpler changes, until a change 
which will allow the task to be covered is found, or 
the variable’s domain is exhausted. This procedure 
ensures that the first value in the domain which can 
be assigned to the task is found, thus observing the 
preference ordering of the values. 

In all cases, potential changes to the current solu- 
tion are checked against the constraints, so that even 
when new constraints are introduced (e.g. an upper 
limit on the number of junior lists a Regis trar on a 
training block can do in a week, as mentioned above), 
the algorithm still produces a feasible solution. 

The local improvement algorithm works through 
the list of uncovered tasks once, and then presents the 
resulting solution as the best that it can achieve. The 
combination of swaps and moves seems to be adequate 
to produce an optimal rota; so far, we have not been 
able to see any further scope for reducing the number 
of uncovered tasks in the rotas produced, except by 
relaxing the constraints. 

Producing the Rota 

At this point, the rota will have several gaps, where 
~ luf anaesthetist has not been assigned to do anything. 
The final stage in constructing the rota is to assign 
the optional lists to fill these gaps. The resulting rota 
is then printed out, with a note of any remaining un- 
covered junior lists. 

The Admin SR may still wish to make changes to 
the rota before it is issued. This is partly because 
there may be places in the rota where an anaesthetist 
has not been found anything to do; since the workload 
varies so much from week to week, there are often ses- 
sions where there are fewer tasks than available anaes- 
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thetists, as well a 8 sessions in the same week where ses- 
sions have to be left unassigned. The Admin SR can 
assign spare anaesthetists to give additional assistance 
at operating lists which have already been covered. 
Occasionally, when there are outstanding unassigned 
tasks, the Admin SR may be able to relax the con- 
straints in order to allow them to be covered. Even 
when the system does not produce immediately us- 
able rotas, the remaining tidying-up takes only a few 
minutes: the difficult part of the job has been done. 

Alternative Approaches 

Dhar and Ranganathan [1] describe a similar prob- 
lem to rota compilation (that of assigning teaching fac- 
ulty to courses) and compare an integer programming 
formulation to an expert system. In their expert sys- 
tem, production rules are used to express both prob- 
lem solving knowledge and constraint knowledge. In 
the rota compilation problem, however, expert prob- 
lem solving knowledge is not easily available. The Ad- 
min SR changes every few months, so that there is not 
usually sufficient time to develop any great expertise 
and there is little opportunity to pass on experience 
from one incumbent to the next; each person therefore 
evolves their own method of rota compilation, based 
largely on trial and error. It seemed best, therefore, to 
use an algorithmic approach to constructing the rota 
and to use the successive Admin SRs only as a source 
of constraint knowledge. 

There is scope, however, for making more use of 
problem solving knowledge in rota compilation. For 
instance, at present there is no attempt to identify 
the session which will be most difficult to cover and 
to assign the tasks in that session first. Hitherto, this 
has not been important because there has been lit- 
tle interaction between the different sessions; the con- 
straints are for the most part between tasks in the 
same session. If the interaction between sessions in- 
creased, then it could become important to use this 
kind of problem-solving knowledge, by using it to di- 
rect the order in which the forward checking algorithm 
considers variables. 

Results and Conclusions 

The rota compilation system has been developed in 
Common LISP on a Sun 3/160; it is now also run- 
ning on a PC. It can produce a weekly rota within 30 
minutes, including entering the required data, com- 
pared with the half day allocated to compiling the 
rota manually. The system has been producing good 
quality rotas for the L.G.I. for over a year, and has 
coped with changes in the rota compilation rules. We 
are currently improving the user interface so that the 
system can be used by hospital staff. In future, we in- 
tend to investigate similar problems in other hospitals 
and to extend the system to deal with them. 

Apart from the fact that the system saves the Ad- 
min SR several hours work each week, with less risk 
that a task will be forgotten, another benefit is that 
it can be used to evaluate different policies, reflected 
in different sets of constraints. A series of rotas which 


would result from the different policies can be pro- 
duced and compared, using real data on absences, etc., 
from past weeks. Hitherto, there has been no way of 
evaluating the effects of proposed changes in policy. 

A common approach in Operational Research to op- 
timization problems which cannot be solved exactly 
is to find (somehow) a feasible solution and then to 
look for local improvements which will hopefully pro- 
duce an acceptable solution. Incorporating the two 
stages, of fluffing a feasible solution and then improv- 
ing it, into the constraint satisfaction framework has 
a number of benefits. First, constraint satisfaction 
seems a natural way of formulating many discrete op- 
timization problems; there is a close correspondence 
between the variables and values of the CSP and prob- 
lem entities. In OR approaches, on the other hand, 
especially those based on mathematical programming 
formulations, there may be a significant translation 
gap between the original problem and its formulation. 
Secondly, since there are already CSP algorithms, a 
means of finding a feasible solution is readily avail- 
able: it is not necessary to write a special-purpose 
algorithm. 

Finally, the local improvement algorithm can make 
use of the constraints, as expr essed in the CSP formu- 
lation, to ensure that any changes maintain feasibility. 
This has been demonstrated in the rota compilation 
system, when a new constraint has been introduced. 
Adding a constraint to the CSP requires only a few 
lines of LISP; the local improvement algorithm needs 
no modification at all, since it merely checks any po- 
tential changes against the new constraint. Hence, 
building the local improvement algorithm within the 
CSP framework gives a very flexible and easily modi- 
fied system, which would be hard to achieve otherwise. 
Although the system described here is very special- 
ized, the general approach of finding a feasible solution 
and then improving it, all within the CSP framework, 
is one that might be applicable to many optimisation 
problems in scheduling. 
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Abstract* 

Techniques that enable humans and machines to co- 
operate in the solution of complex s cheduling 
problems have evolved out of work on the daily 
allocation and scheduling of Tactical Air Force 
resources. A generalized, formal model of these 
applied techniques is being developed. It is called 
JIGSAW by analogy with the multi-agent constructive 
process used when solving jigsaw puzzles. JIGSAW 
begins from this analogy and extends it by propagating 
local preferences into global statistics that dynamically 
influence die value and variable ordering decisions. 
The statistical projections also apply to abstract 
resources and time periods — allowing more oppor- 
tunities to find a successful variable ordering by 
reserving abstract resources and deferring the choice of 
a specific resource or time period. 

Keywords: Scheduling, constraint propagation, 
statistical look-ahead, hierarchical planning, resource 
abstractions, transformational synthesis. 


1. Introduction 

For many scheduling problems, partial automation 
is a realistic but diffic ult goal. Partial automation 
means that human schedulers can participate in incre- 
mental scheduling decisions. Algorithms from oper- 
ations research and most heuristic search techniques 
involve humans in the problem set up but not in die 
generation of schedules. These algorithms work well 
when the problem is modeled perfecdy and is 
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computationally tractable. Unfortunately, practical 
scheduling problems occur in very complex environ- 
ments, it is usually impossible to capture all of the 
domain complexities in the formal model. In practice, 
the results of fully automated scheduling algorithms 
are used primarily to debug the problem set up. This 
results in a very large debugging loop that is inefficient 
and does not always converge to an acceptable 
solution. Furthermore, details about myriads of 
individual preferences are seldom handled effectively. 
While a human scheduler may notice that an important 
task in today's schedule is one on which John Jones 
performed effectively last week, it is impractical to 
expect that the knowledge acquisition task can capture 
all these subtle preferences in advance. 

A co-operative approach to schedule generation 
exploits the strengths of both humans and automation, 
but co-operation implies that the scheduling software 
has to work with an incomplete model of the problem 
domain. Human scheduling decisions should be 
viewed as dynamic extensions to that model. 

- Furthermore, many scheduling problems are 

- dominated by preferences rather than by hard 
constraints, and these preferences need to be exploited 
in the same way that constraints are exploited in 
constraint-directed scheduling. 

2. Background and Overview 

JIGSAW generalizes techniques originally 

developed to partially automate the daily allocation and 

... scheduling of Tactical Air Force resources. The 
complexity of the knowledge involved in this 
scheduling problem is such that, when done manua lly, 
a team of 8-16 people works over a period of 12 or 
more hours. An interactive system that solves this 
problem by allowing humans and the mach ine to make 
incremental scheduling decisions was designed three 


141 



years ago, has undergone two years of user 
evaluations, 1 and is now being hardened for 
operational use. JIGSAW is a generalization and 
formalization of the automated reasoning techniques 
originally designed for this application. 

JIGSAW is an open collection of techniques that 
allow humans to participate as schedules are con- 
structed incrementally. JIGSAW begins with a trans- 
formational approach — similar to the transformations 
commonly used to compile program specifications into 
programs and to refine design specifications into 
designs. Correctness-preserving transformations 
encapsulate knowledge about incremental allocation 
ami scheduling decisions. They separate the definition 
of these decision rules from die control decisions about 
when they should be invoked. 

JIGSAW extends this transformational approach 
with statistical look-ahead techniques. Statistical look- 
ahead uses local constraints and preferences to project 
the expected contention for resources over time. These 
statistical projections allow local scheduling decisions 
to be influenced by statistical knowledge about the 
global context Statistical look-ahead enhances both 
value and variable ordering techniques. Our ongoing 
work extends these statistical projections to deal with 
abstract resource groupings. Partially determined time 
intervals are also handled as abstract resources. An 
assignment of an abstract resource to a task creates a 
reservation for an unspecified instance of the abstract 
resource. These reservations for abstract resources 
enable incremental commitments that provide more 
opportunities to find variable orderings that avoid or 
reduce backtracking. 

The name JIGSAW is based on an analogy with 
jigsaw puzzles where: 

• Many Independent agents— both human and 
automated — co-operate to construct a solution. 

• The order in which scheduling decisions 
are made is not predetermined by the 
problem. 

• Partial solutions can (usually) be evaluated as 
(probably) extensible to an acceptable solution. 

JIGSAW extends this analogy with a combination 
of techniques for reasoning about preferences, 
abstraction levels, variable ordering, and uncertainty. 
Unlike jigsaw puzzles, JIGSAW seeks a globally good 
solution by m akin g a series of local decisions that are 


1 The realities of a large implementation have led to an 

early focus on machine assistance for human decision- 
making; implementation of die automated decision-making 
t»rfiniqiM» on which JIGSAW is based is quite recent 


informed by statistical knowledge about how the local 
decision is likely to impact global optimality. 

The overall JIGSAW approach involves associating 
a transformation with each incremental, atomic 
allocation and scheduling decision. The users can 
commit some scheduling decisions, and the automated 
JIGSAW techniques accept and work with partial 
schedules developed by users. The users control 
which transformations will be candidates for 
execution. The control software invokes the 
transformations that produce the most promising 
extensions of die current partial schedule. 

3, Exploiting Value and Variable 
Ordering Opportunities 

To fully exploit value and variable ordering 
opportunities when constructing a schedule 
incrementally, individual transformations of partial 
assignments should be kept as atomic as possible. 
Most job shop scheduling techniques exploi t vari able 
ordering opportunities only at the level of complete 
orders or resources; that is, they make assignments to 
all the tasks involved in an order or they completely 
schedule a single resource. Like Cortes [Fox & 
Sycara 90, Sadeh 91], JIGSAW enables separate 
decisions for each ^individual task or activity. 2 
JIGSAW allows a task to be assigned a resource or 
scheduled into a time period without simultaneously 
committing to decisions about other tasks or times. 
Furthermore, by Introducing resource abstraction 
hierarchies, JIGSAW can reserve an abstract resource 
for a task while deferring the assignment of a specific 
resource or time interval. These assignments of 
abstract resources allow more opportunities for 
variable ordering heuristics to be effective. 

When allowing very small incremental trans- 
formations that may be made in almost any order, one 
has a problem preserving the property that any partial 
assignment that is generated can be extended to a 
nearly optimal solution. In particular, related tasks 
must all eventually receive consistent assignments, 
tasks that are assigned an abstract resource must 
eventually receive specific resources, tasks that receive 
resources must eventually be scheduled, and tasks 
assigned a flexible time period must eventually be 
scheduled into a specific time interval. Th ese 
problems are largely avoided in earlier scheduling 
systems where all of the decisions associated with an 
order or resource are made simultaneously; however, 


2 JIGSAW’S tasks are equivalent to Cortes' activities. 
The terms “operation” and ‘Variable” are also used in the 
literature with an equivalent meaning. 
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this grouping of decisions limits die opportunities to 
fully exploit value and variable orderings. 

JIGSAW includes substantial bookkeeping func- 
tions and statistics that summarize the state of current 
assignments and project die probable effects of future 
assignments. This information is used to inhibit trans- 
formations that are likely to interfere with the 
completion of existing partial assignments. Projec- 
tions about die expected demand on resources allow 
the incremental transformations to achieve a bal ance 
between greedy local optimization and altruistic 
minimization of resource conflicts [Sycara et al. 90]. 
The bookkeeping functions and statistics apply to 
abstract as well as specific resources and time periods. 
Reservation for abstract resources are guaranteed in 
that transformations making assi gnme nts to other tasks 
will preserve enough instances of the abstract resource 
to fulfill all prior reservations. Significantly, many of 
these same bookkeeping functions and statistics are 
also useful to die human experts who co-operate in the 
;7 problem solving process. 

The bookkeeping functions and statistics are also 
used to dynamically select the order in which the 
tranrfonnations are executed. The goal is to defer each 
transformation until there is enough information 
available to predict that its decision is a step toward 
achieving a nearly optimal assignment Note that if all 
transformations meet this goal, then whenever a 
specific task-resource or task-time-period pairing is 
required to achieve an optimal assignment, other 
transformations will not use up the last instance of the 
resource or time period that is needed by this task Of 
course, with invocation criteria as stringent as this, the 
problem is whether there will always be a 
transformation that does not need to be deferred. An 
expe rim e nt al hypothesis being evaluated is: for many 
large problems that are characterized by many 
preferences and that can be solved adequately by trams 
of human experts, there will usually be some 
“obvious” transformation that does not need to be 
deferred. When there is no such transformation, then 
either human intervention or a branch and bound 
search strategy can be used effectively. 

In summary, the automated portion of JIGSAW 
starts from any consistent partial assignment (initially 
from tiie empty assignment unless human experts 
make some initial decisions), finds a transformation 
that is statistically the least in need of being deferred, 
executes that transformation, and iterates. Humans 
control the overall process and can interleave their own 
decisions between transaction invocations. 

4. Statistical Projections 

In tiie Tactical Air Force application, statistical look- 
ahead was used to give more sophistication to what is 


basically a greedy algorithm augmented with plan 
repair techniques. However, the statistical look-ahead 
techniques together with reservations for abstract 
resources also work in the context of backtracking or 
breadth-first search strategies. The choice of tie 
search strategy is controlled by the size of the problem 
and the need to interact with human schedulers, not by 
the statistical look-ahead. Human schedulers appear to 
be most comfortable with divide-and-conquer, greedy 
algorithms, and plan repair strategies — together with a 
very limited amount of breadth-first search and 
backtracking. 

The critical part of JIGSAW is the inner loop where 
statistics about expected resource availability am 
projected and a transformation that does not need to be 
deferred is found. This section summarizes the steps 
used in the Tactical Air Force scheduling problem from 
which JIGSAW evolved. A more formal, general 
treatment can be found in [Linden 91], and we are 
currently trying to formalize these ideas more directly 
in terms of Bayesian networks and decison theory. 

This description of the inner loop in JIGSAW is a 
step toward generalizing the computations, not 
optimizing them. The Air Force application where 
these techniques were applied deals with the 
optimization issues; many optimizations are available 
by reusing previous computations. 

The steps of tiie inner loop are: 

1. Local rating: Use constraints to identify the 
alternative resources and time periods that can be 
assigned to each task, and use preferences to order 
or rate these possible values. This local rating is 
based on the easily-processed constraints and 
preferences directly associated with the task; 
initially, it does not deal with global issues like 
resource availability. 

2. Global statistics: Translate the local ratings for 
each alternative value assignment into a subjective 
probability that this assignment will be made, and 

sum these probabilities across all the tasks to project 

global statistics about the expected demand for each 
: - resource. Comparison of the expected demand for 
resources with tiie available resources identifi es 
probable bottlenecks. 

3. Trade off: Re-evaluate the alternative value 
assignments in terms of which choice is most likely 
to be part of a globally optimal assignment This 
re-evaluation uses the statistics about resource 
contention and makes a trade off between local 

— utility and global resource contention. 

4. Commit: For one or more, tasks, “commit” to a 
transformation that is projected to lead toward a 
good complete assignment Choose to make this 
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commitment for tasks where the decision is 
“obvious” and/or “influential”: 

a. Obvious decisions are those where one can 
project a very high confidence level that a 
decision made now will be “right.” This 
confidence is evaluated in terms of: 

• Strength of the local preference for the 
proposed commitment relative to alternative 
possible values. This may be computed as 
the delta between the rating of the value to 
be committed and the rating of the next best 
value. 

- The commitment’s use of low contention 
resources based on the statistical projections 
of the expected demand for each resource at 
various times. 

- The quality of the current understanding 
about how interactions with other tasks 
might affect this task. 

b. Influential decisions are decisions which 
clarify many other decisions; for example, a 
decision to commit bottleneck resources is 
influential because it narrows the choices that 
remain open for all others decisions. 

5) Plan repair: Plan critics are available as a way of 
undoing a previous decision — along with the 
decisions that directly depend on it Plan critics 
resolve conflicts that arise from imperfect look- 
ahead or from changing conditions in the external 
environment Plan critics have been included in the 
design of JIGSAW applications, but they have not 
yet been added to the formal JIGSAW model. 

5. Conclusions 

JIGSAW evolved from work on large scheduling 
applications that must be solved co-operatively and are 
dominated by preferences rather than by hard 
constraints. JIGSAW exploits those preferences to 
project statistical characteristics of the global situation 
which are then used to enhance local value and variable 
orderi ng d ecisions. JIGSAW extends these statistical 
projections to abstract groupings of resources and 
allows partial schedules to include reservations for 
abstract res ources. These reservations for abstract 
resources' open more opportunities for value and 
variable ordering techniques to be effective. 

JIGSAW is proposed as one of a range of 
scheduling techniques It Is appropriate for large 
resource allocation and scheduling applications that are 
currently solved by teams of human experts. It is 
especially appropriate for problems where the 
evaluation criteria are complex, changing, and not fully 
formalized— problems for which human schedulers 


need to be involved to help evaluate the feasibility and 

effectiveness of the evolving schedules. 
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Abstract 

The intention of the scheduling system developed at the Fraunhofer-Institute for Material How and 
Logistics is the support of a scheduler walking in a job-shop. Due to the existing requirements for a 
job-shop scheduling system the usage of flexible knowledge representation and processing twrhniq n^ 
is necessary. Within this system the attempt was made to combine the advantages of symbolic AI- 
techniques with those of neural networks. 
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System structure 

The scheduling system is situated below a 
MRP system giving the relevant data for the 
schedule generation. This data contains 
information about the orders, work plans and 
resources, the optimization goals and the 
strategies. Out of this data local, global and 
strategic constraints are generated. 

The local constraints describe the strict 
requirements the schedule has to fullfiL 7111686 
are the sequence of operations, the demand for 
resources, the capacity restriction of resources, 
and the due dates. Beside the strict 


requirements global optimization goals have to 
be considered within the schedule. An 
opti mi za ti on goal consists of an optimization 
criterion whose value describes certain costs 
(throughput time, resource utilization, 
inventory, tardiness) and a goal description 
(m i nim i z ation of throughput time, minimization 
of weighted resource utilization, ...). These 
global constraints represent the optimization 
goals as preferences. Strategies for building up 
and refining a schedule are formulated as 
strategic constraints. These strategic constraints 
contains a description about when certain 
strategies can be used, where the schedule can 
be made more detailled, how specific situations 
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can be detected and what kind of actions have 
to take place, how the data of the schedule can 
be aggregated to make the detection of 
situations possible, and how specific 
requirements of the factory can be taken into 
account All three type of constraints are used 


Generation of the schedule ^ 

For the generation of the schedule all three _ 

schedulers work on it while the information 9 

between them is exchanged through the 
partially detailled schedule. The process of the _ 


Material Raqutramant and Planning System 





by the different schedulers (local, global, 
strategic) to build up a schedule. The structure 
of the scheduling system is shown in Fig. 1. 


schedule generation can be described as 
follows. In a first phase the local scheduler 
makes a preliminary analysis of the starting 
time for every operation. This analysis is done 
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with respect to the strict requirements and 
preferences the schedule should fulfill. The 
possible starting times are determined through 
the propagation of the local constraints within 
so called suitability functions [JOHNSTON 89]. 
Suitability functions describe for every 
operation how desirable it is to start it at a 
certain time, so they can be described as 
functions over the time (Fig. 2). When the 
value of a suitability function for an operation 
is zero this operation cannot be started at that 
time. The local scheduler generates a schedule 
in which all times where an operation cannot 
start are excluded. The propagation of the local 
constraints are based onto Allen's time relations 
[ALLEN 83], the values of the constraints being 
suitability functions (Fig. 3). 



Fig. 2: Example of suitability function before 
propagation 

Each time relation is expressed by a utility 
function (Fig. 4). This type of function 
represents a relative measure for the preference 
of the starting time of an operation. In an 
extention of the time relations static constraints 
for the first possible start time, the least 
possible end time, and the capacity of a 
resource are built 



Fig. 3: Constraints as utility functions 

In each propagation step an operation is chosen 
and for each constraint to another operation a 
sub-suitability function is being built The 
result is a suitability that shows the possible 
starting times of this operation under a 
constraint 

Cl 



Fig. 4 : Resulting sub-suitability functions 

At each propagation step the new suitability 
function is formed out of die product of all sub- 
suitabilites and the static suitabilities. Within 
this new suitability all constraints have been 
taken into account (Fig. 5). If the suitability 
function has changed all suitabilities of a 
constrained operation must be updated. When 
no suitability changes anymore die propagation 
ends. In the CSP - notation this propagation 
creates an arc consistent graph. 


new 
opl 

Fig. 5: Suitability Function after propagation 

Besides the strict requirements the global 
optimization goals should also be considered 
within the schedule. This is done by the global 
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scheduler which refines the possible starting 
tunes of every operation by using a neural 
network. 

This neural network is built up based upon the 
possible starting times determined through the 
local scheduler. The neural network is a 
Guarded-Discrete-Stochastic Network (GDS) a 
special type of Hopfieid net [JOHNSTON/ 
Adorf 89], [Minton et al. 90], [Hopfield/ 
Tank 85], [HOPFIELD/TANK 86]. The main 
idea is a unit guarding a subset of normal units, 
so that it is guaranteed that one unit is active. In 
the scheduling domain it helps to generate 
schedules for all operations and resources and 
not for a subset what would only be possible 
with Hopfleld-nets [JOHNSTON/ ADORF 89]. 
The net is divided into two parts, the operation 
net and die resource net The weights between 
the units of the operation net are explicidy set 
by die goals of the optimization (minimization 
of throughput time, weighted resource 
utilization, tardiness and work in progress). All 
units have a bias which is based on the results 
of the local scheduler, thus representing the 
suitability functions. Hie activation of the units 
of the operation net corresponds to it's 
preferred start time interval while the activation 
of the resource units represent the remaining 
capacity in that time interval. 

The net is arranged in a matrix-like manner. 
While die rows represent the operations and 
resources, the columns contain the time 
intervals in which the suitability functions of all 
operations are constant The update of all units 
of both nets is done synchronically with the 
same probability and regarding the state of the 
guarding units. The convergence of GDS- 
networks is not guaranteed, and so we impose 


a restriction on the number of epochs 
[JOHNSTON/ADORF 89]. The result of a stable 
state of the neural network is an optimized 
schedule with respect to the different 
optimization goals. 

The local and the global scheduler work on the 
schedule as a whole, i.e. changes in the 
schedule affect all operations. These changes 
are generally rather coarse. The strategic 
scheduler on the other hand selects one 
operation out of the schedule for which it does 
a detailled planning. The strategies the 
scheduler uses for this are described within the 
strategic constraints. Strategic constraints are 
formulated as rules on four levels of 
abstraction: 

• metarules 

These rules describe which strategies are 
adequate at certain states of the schedule. 

• strategies 

The strategies describe how to refine the 
schedule (e.g. scheduling the critical 
operations first) taking into account the 
state of all operations and resources. 

• situation & action 

These rales are used to detect situations^ 
(e.g. when an operation is critical) and to 
suggest actions (e.g. scheduling an 
operation in it’s preferred time interval). 
The view of these rules is local, looking 
at the actual state of an operation or 
resource within the schedule. 
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• transformation & reduction 

With these rules the actual state of the 
current schedule can be reduced to the 
relevant informations (e.g. the preferred 
time interval for starting an operation) 
used by the rules of the higher abstraction^ 
levels. 

As a first step the strategic scheduler selects an 
adequate strategy by using the metarules. The 
strategies suggest detailled changes for the 
scheduling of a selected operation. This 
selection is done by the strategic constraints 
describing the situation & action and 
transformation & reduction. The suggestions 
are based upon the actual schedule containing 
the possible and the preferred starting times for 
each operation as a result of the local and the 
global scheduler. The suggestion which seems 
to have the most promising effects on the 
schedule is integrated into the schedule and die 
effects are propagated through the suitability 
functions using die local scheduler. This cycle 
(local - global - strategic scheduling) continues 
until all operations are scheduled. In the case 
that the decision of the strategic scheduler leads 
to an inconsistent schedule this decision and all 
it’s effects have to be retracted and an 
alternative has to be chosen. This work is done 
by a control component. The work of the three 
schedulers can be seen as a stepwise refinement 
of the schedule. The possible starting times for 
each operation are repeatedly restricted until a 
sufficient exact starting point or a sufficient 
small interval for the starting time is 
determined. 


At the moment the system described above is in 
the state of implementation. So a judgement 
about the quality of die scheduling system can’t 
be done yet But the parts implemented so far 
show promising results, so that we are rather 
hopeful about fulfilling the objectives the 
system should meet concerning the quality of 
the schedule. 
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Abstract 

Scheduling can be formalized as a Constraint Satisfac- 
tion Problem (CSP). Within this framework activities 
belonging to a plan are interconnected via temporal 
constraints that account for slack among them. Tempo- 
ral representation must include methods for constraints 
propagation and provide a logic for symbolic and nu- 
merical deductions. 

In this paper we describe a support framework for 
opportunistic reasoning in constraint directed schedul- 
ing- In-order to focus the attention of an increment al 
scheduler on critical problem^ aspects, some discrete 
temporal indexes are presented. They are also useful for 
the prediction of die degree of resources contention. 

The predictive method expressed through our indexes 
can be seen as a Knowledge Source for an opportunistic 
scheduler with a blackboard architecture. 

1. Formalization of scheduling problem and 
strategies for its solution 

Scheduling can be formalized as a Constraint Satisfac- 
tion Problem (CSP)fKeng and Yun, 1989]. This ap- 
proach is concerned with the assignment of values to 
variables subject to a set of constraints. In scheduling 
variables are constituted by activities start times and 
from resources allocation; for this reason we have to 
deal explicitely with two types of constraints: temporal 
relations among tasks and resources capacity [Fox, 86]. 

In our approach we assume that we have a set of plans 
to be scheduled, where a plan is defined as a partial 
ordering of activities. Each activity may require one or 
more resources and for each of them there can be 
alternative choices. Beside resources capacity can be 
used contemporariy by different tasks; for the sake of 
simplicity we will assume all resources with unary 
capacity. 

Scheduling is an NP-hard problem and methods re- 
quired for its solution must face this complexity. In our 
research we decided to focus our attention on contribu- 
tion in scheduling coming from AI, and particularly on 
opportunistic reasoning [Hayes-Roth, 79]. 


We are concerned with the issue of how it’s possible to 
focus the attention of an incremental scheduler on die 
most critical scheduling choices in order to evaluate 
which are the most critical points, which decisions seem 
to be the most promising in reducing search complexity 
and improving quality of resulting schedule. 

Our strategy is to identify the most "solvable" aspects 
of the problem through the evaluation of the degree of 
interaction existing among activities belonging to dif- 
ferent orders. The aim is to reduce the number of steps 
required to obtain a solution. 

The necessity to overcome the limits of partial decom- 
position approach, such as order-based and resource- 
based decompositions, has led us towards an 
event-based perspective whit chronologically-grouped 
information. - - =- - 

This basic search strategy is realized through most -con- 
strained and least-impact policies. Every step is divided 
into two parts; first the most-constrained policy selects 
dynamically on which agent must be focused schedul- 
ing attention; then, die least-impact policy chooses for 
that agent a value whose impact on the rest of the 
non-scheduled agents is as small as possibile. The goal 
is the identification of critical activities that heavily rely 
on the possession of highly contended temporal inter- 
vals or resources because of intra-order and inter-order *« 
interactions (look-ahead strategy). 

This two policies need numeric indexes which, analyz- 
ing the particular structure of a problem, are able to 
measure the interaction among activities and resources 
in terms of variable looseness and value goodness 
[Sadeb and Fox, 88]. . . - - 

Variable looseness is die measure of how constrained 
is a resource or an activity, value goodness measures 
which variable value, among all the feasible ones, gives 
the least impact (i.e. a sort of maximum slack) on 
availability of feasible (and good) values for non-sche- 
duled variables. 

We identified some numeric indexes that contain infor- 
mation required to realize an event-based policy: three 
indexes are useful for different reasons: 
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D they make possible to point out critical resources 
ana activities; 

n they identify "island of certainty" that will be a 
part of problem solution; 

n they give information about activities start times 
that nave the least impact on non-scheduled acti- 
vities. 

This behaviour is a sort of "opportunistic reasoning" 
[Hayes-Roth, 79]: this term has been used to charac- 
terize a problem-solving process where reasoning is 
consistently directed towards those actions that appear 
most promising for solving a problem. 

Our predictive approach, used together with an oppor- 
tunistic reasoning, is also useful to detect unsatistiable 
CSPs as soon as possible, simply by analyzing the 
indexes we defined. In this sense the system can be 
viewed as a Knowledge Source in a blackboard archi- 
tecture. which assumes responsibility for preventive 
analysis of activities interactions and for the detection 
of prospective bottlenecks. 

2. The predictive approach: basic assumptions 

The main goal of our research was to provide a simple 
but complete inference mechanism to support schedul- 
ing, working in a discrete time domain. This mechanism 
is based on some indexes and is designed to perform an 
a-priori guidance for search in scheduling domain. We 
kept a particular attention on the efficiency and on the 
speed of such a mechanism, because we realized that 
such properties are necessary in scheduling systems for 
real applicative environments like, for instance, manu- 
facturing ones. For this reason we decide to consider a 
discrete representation of time instead of a continous 
one. 

Our indexes are based on the constraints analysis (and 
on the propagation of the temporal ones) and on a 
particular representation of existing time relations. 

In terms of constraints analysis we differentiate be- 
tween restrictions and preferences [Fox, 86]. Temporal 
preferences are represented through utility functions 
defined on activity start times that maps possible values 
onto utility levels ranging from 0 to 1. Moreover in our 
analysis we consider the existence of intra-order 
(among activities belonging to an order) and inter-order 
constraints (among activities belonging to different or- 
ders). 

The model adoptated in representing time and in rea- 
soning about temporal relation is based on the concept 
of lapse, that is defined as the period of time associated 
with an activity. In a temporal axis a lapse is represented 
by two temporal parameters, namely start time and end 
time. Relations between different lapses are expressed 
by two parameters [Paolucci, 90]: 


° an internal bound (INT), which represents the 
minitnun time interval which must separate the 
end of the first lapse from the begin of the second 
of two related lapses; 

° an external bound (EXT), which represents the 
maximum time interval from the begin of the first 
lapse to the end of the second. 

Through these two parameters it's possible to model 
any temporal relation in a scheduling problem. They are 
simpler than thirteen Alien 's primitive relations; more- 
over, INT and EXT improve greatly the efficiency of 
numeric temporal reasoning, that is instead a limit in 
Allen’s primitive. 

3. The Predit indexes 

Temporal relation constraints are used to describe par- 
tial orderings among activities as provided by the pro- 
cess planning step. 

We will refer to the graph defined by these constraints, 
for a given CSP, as the CSP's Temporal Constraint 
Graphs (TCG). 

We have to schedule a set of activities (A 1 ,A2,...,AN). 
Let Ik be the time interval associated with Ak. Activities 
are connected by a set of temporal relation constraints, 
thereby forming a TCG. We view TCGs as undirected 
graphs. An Arc in a TCG indicates the presence of a 
temporal relation between two intervals represented by 
the couple INT-EXT (Fig. 1). 



L EXT 


Figure 1 

Additionally there are capacity constraints limiting the 
use of each resource to only one activity at a time. The 
next example presents a simple case of a TCG com- 
posed of two orders. 

In order to provide a predictive support for opportunis- 
j>tic schedulers operating in a discrete time domain we 
have considered interactions among activities caused 
by temporal relations. 

The first issue we faced was to detect as soon as possible 
during the scheduling the possible arising of conflicts 
due to interactions among activities. 
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For this issue we defined an index called Constraint 
Degree (CD), which measures the how tight is the link 
existing between two generic activities Ai and Aj con- 
nected by a temporal relation constraint (represented by 
INT-EXT) in a contraint graph. 

Temporal relations between intervals may simply be 
expressed by using potential inequalities associated 
with die bounds of intervals such as : 

[1] Di + Dj + INT S ETj - STi 

[2] Di + Dj + INT £ EXT 

The first inequality verifies that time interval composed 
of activities durations and Internal Bound is included in 
maximum temporal window allowed by Aj latest end 
time and Ai earliest start time. 

The second inequality controls that the same time inter- 
val doesn’t violate External Bound temporal constraint 
These inequalities lead to define the CD formula 
through a multiplication of their members: 


[3] 


cot - ( a ± DuJNT ) 8 
* EXT * ( ETj - STi ) 

6 £ CDjj £ 1 


Die = Ak duration INT = internal bound be- 
tween Ai and Aj 

STk = Ak start time EXT = external bound be- 
tween Ai and Aj 

ETk = Ak end time 


The Constraint Degree is calculated on the notion of 
slack between two activities tied by temporal links. 

D CDij * 1 means that Ai allows no slack to Aj 
(most constrained) 

D CDij *0 means that Ai allows maximum slack to 
Aj. 

The CD computational algorithm considers all con- 
nected activities from the beginning to the end of the 
graph. Therefore, for ending activities we set CD index 
to zero (ending activities are not constrained, with tem- 
poral relation, with any other activity in the graph). 

The validity of CD index is preserved by a pre viou s 
optimization procedure in order to adjust activitiesTem- 
poral windows cutting out start time values drat can 
never be involved in CD computation (the same is 
made for other indexes). 


To sum up, the CD index detects (followi ng the most - 
constrained policy) die most critical activities with re- 
spect to intra-order temporal relations (expressed by 
INT and EXT) and to temporal windows (expressed by 
activity start and end time). 

The second index, called Preferential Start Time 
(PST), is a local measure of value goodness and glo- 
bally, a measure of variable looseness for activities start 
times. It helps in choosing among all admissible start 
times die one that minimizes future conflicts. It is 
calculated between each pair of activities connected in 
the TOG (i.e. Ai and Aj) and it depends on the start time 
of the first activity (i.e. sti). 

The main goal of PST index was to introduce some 
estimation rule for activity start times in order to ident- 
ify the least impact values arising from intra-order 
interactions. 

PST index is computed for every activity start time sti 
evaluated between earliest start time (STi), or value = 
allowed by INT-EXT, and latest start time (ETi-Di), or 
value allowed by INT-EXT, increasing sti with the fixed 
time unit 

PST is expressed by the ratio: 


[4] PSTy ( sti ) 


Mtjj ( sti ) 

EXT-D, - Dj - INT 


0 S PSTy ( Sti ) S 1 


where: 

n intij(sti ) = relative internal bound 

B EXT-Dj-Dj-INT = maximum slack between the 
activities 

The numerator is calculated for stj val u es fr om Earliest 
Start Tune to the maximum allowed by temporal con- 
straints, increasing each time sti with a chosen time unit. 
It may be also considered as "actual" slack between the 
two activites corresponding to sti value. 

Therefore, the denominator may be viewed as the maxi- 
mum slack between the two activities. The closer is 
PSTij value to one, die greater is the slack between Ai 
and Aj. Therefore, for a generic activity PST measures 
for each admissible start time its goodness and likeli- 
hood to minimize future scheduling conflicts. 

To compute aefii^iMjffiriual Demand formmiifWM, 
we have combined die value goodness of every start 
time (expressed by PSD with the activities durations. 
Moreover, as assumed in [Sadeh-Fox, 88], an activity 
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At can use a resource Rj if Ai is active at time t and A; 
uses Rj at time t to fulfill its resource requirement 

From each PST graph we achieve an Individual De- 
mand graph (whose values are expressed by ID index) 
for each activity, expanding PST values with a lapse 
equal to the activity duration and adding all values in 
function of time. We obtain a histogram representing 
activity resource demand in function of time . 

Individual Demand values are combined to measure 
resource Aggregate Demand (AD), always in function 
of time. AD shows when resource competition is par- 
ticularly high and which are activities that heavily rely 
in the possession of these resources. AD values must be 
tightly evaluated in function of time because temporal 
constraint propagation doesn't allow for any resource 
preference (as explained before, we assume all resour- 
ces with unary capacity). Therefore, AD index can 
estimate the amount of contention for each resource 
over temporal axis but only as a function of start time. 
Moreover, it’s easy to improve this approach repre- 
senting, for example, resources preferences with utility 
functions and propagating these resources reservations 
through the TCG graph. 

Figure 2 shows a simple example in order to illustrate 
our graphic results concerning temporal discrete in- 
dexes presented above. 
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Figure 4 

Next results are concerned with the reasonable steps 
that an Opportunistic Scheduler should achieve in order 
to produce the final Gann chart 

Al A2 A3 A4 A5 

0,25 0,2 0.2 0.182 0 

Table 1: CD values for order ] activities 


Figure 2 

The temporal constraint associated at each linker is 
equal for all couple of activity and it is expressed by 
INT=0 and EXT=40. However, these values may be 
optimized as described before. 

Start Tune and End Tune are expressed by numbers 
above each activity and the same is made for requested 
resources. For the sake of simplicity, in this example we 
have not introduced preferential start times (so activity 
start times are equally preferred). 


A6 A7 A8 

0.25 0,25 0 

Table 2: CD values for order 2 activities 


Among the aggregate demands, die most highly con- 
tended resource is R3 (fig. 3), required by A2, A3. A4, 
A7; the next activities we will focus our attention on are 
A4, A3 and A7 (because A2 has an alternative in Rl). 

Taking a look at the CD indexes of order 1 and order 2, 
A7 appears to be the most constrained activity because 
of its highest CD value. Now, A7 PST graph (fig. 4) 
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presents a maximum for t=20 and scheduling A7 with 
st=20 we can assign the resource R1 to the activity A2 
at the same start time. 

The same considerations based on temporal indexes 
evaluation allow the identification of other activity pref- 
erential start times leading to the Gantt chart presented 
below in fig. 5. 
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The quality of a schedule is based on the capability of 
the scheduler to satisfy a set of performance measures. 

Moreover, a satisfiable schedule is always a com- 
promise between the attempt to meet performance re- 
quired mid the necessity to respect all its constraints: 
schedule quality mirrors this trade-off. Each set of 
organizational constraints has its effects on final pro- 
duction schedules and, following the CSP formulation, 
if we change the constraints the solution will change 
too. 

In order to improve schedule quality, our research is 
focusing on die evaluation of which impact might have 
an unexpected event on the resulting solution. PREDIT 
approach through the evaluation of discrete temporal 
indexes produces relatively accurate early predictions 
of activities behaviour as soon as PREDIT receives their 
changes and as long as constraints remain constant 
during indexes computation. The ability to react to 
changes that occur in dynamic environments providing 
a feasible solution in a sufficiently short time is very 
important expecially in manufacturing scheduling do- 
main. 


predictive support in an opportunistic scheduling sys- 
tem. “ '' 


We implemented this model in a MS-DOS environment 
with a particular attention towards speed pe rformances. 
Our experiments indicate that our approach is success- 
ful in supporting opportunistic scheduling. This system 
is very efficient (it takes few seconds to calculate in- 
dexes in non-trivial real problems). r 

Our model seems to be highly appropriate for problems 
where the costs of backtracking is high because it's able 
to point out scheduling decisions that will minimize 
intra-order and inter-order conflicts. It increases signi- 
ficantly the performances of an opportunistic scheduler, 
making it possible to introduce such a tools in real 
applications: ~ 

Moreover the policies used by Predit to control the 
solution search (must constrained and least impact) can 
be used als o in dynamic manufa cturing environments. 
We are developing ourresearch in this sense, also trying 
to support reactive scheduling and to manage multia- 
gent production control systems. 
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4. Concluding remarks 

The approach we presented in this paper constitutes the 
basis for integrating an event-based mechanism and a 
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ABSTRACT 

TMSA is a concept prototype developed to 
support NASA Test Directors (NTDs) in schedule 
execution monitoring during the later stages of a 
Shuttle countdown. The program detects 
qualitative and quantitative constraint 
violations in near real-time. The next version 
will support incremental rescheduling, and 
reason over a substantially larger number of 
scheduled events. 

INTRODUCTION 

The Time Management Situation Assessment 
(TMSA) program is a prototype developed to 
assist NASA Test Directors (NTDs) manage 
the later stages of a Shuttle countdown. The 
NTDs are primarily concerned with the orderly 
and timely execution of the countdown process. 
The cognitive model they reason with is a 
relatively high-level one which includes a 
nominal (planned) model of the countdown and a 
set of qualitative and quantitative constraints 
that define such a countdown by specifying 
temporal duration and ordinal relationships 
between countdown events. Constraints vary 
both in their specificity (e.g. < is more explicit, 
<= is less explicit) and in their necessity (i.e. 
from critical - more necessary to desirable - 
less necessary). 

From the perspective of knowledge engineering 
for TMSA, what is not included in the NTDs* view 
is as important as what is included. The details 
of a subsystem or procedural failure, and what Is 
required to correct or bypass it are not, for the 
purposes of TMSA, a pan of the NTDs* view of the 

•This work is a portion of the technical suppon 
provided to the Artificial Intelligence Section, 
Design Engineering Directorate, by Boeing 
Aerospace Operations under the Engineering 
Support Contract at Kennedy Space Center. 

Arthur E. Beller is the NASA Technical Contact. 


countdown situation. Even in an anomalous 
situation the NTDs’ focus remains on the 
temporal duration and ordinal unfolding of the 
countdown. When an anomaly occurs the NTDs 
participate in the anomaly response, primarily, 
for the purpose of determining the impact the 
anomaly will have on the temporal and ordinal 
aspects of the countdown. 

The NTDs monitor the current countdown and 
assess its compliance with their nominal 
countdown model. When there is a need for a 
deviation, they consider alternative revisions of 
the current countdown and assess the legality 
and desirability of the revised countdown with 
regard to the constraints. The countdown 
schedule may be revised by reordering events 
and/or adjusting the durations of intervals 
between events. 

The existing prototype monitors launch 
processing during the later stages of the 
countdown. It detects deviations from a nominal 
countdown by detecting temporal 4nd 
prerequisite constraint violations. It then 
identifies the violated constraint(s). The system 
is initialized and operates with both qualitative 
and quantitative constraints on the order of 
events and intervals, and the duration of 
intervals. 

The prototype is implemented in Smalltalk and 
runs on a 25mhz 486, under MS DOS. It appears 
that a C++ version of the program will be able to 
handle a schedule containing 200-300 events 
with response times of < 1 JS seconds for each 
assimilation input (i.e. relation vector 
refinement). 

SALIENT CHARACTERISTICS OF THE SITUATION 
In formulating our approach to this scheduling 
task we found the following characteristics of 
the situation to be especially important. 
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1. The situation is highly structured. A pre- 
existing nominal schedule is available. There is 
a well formulated, proven set of constraints on 
the schedule. The horizon for rescheduling is 
limited by fixed synchronization points which 
divide and encapsulate the countdown schedule. 
All possible events in the countdown are known 
and are of limited number. 

2. Although this is an advisory system used by 
experts, the criticality of the situation places a 
premium on timeliness and correctness beyond 
that of many applications. Near real-time (< lJ 
second) responses and an assurance of 
correctness are required. Rescheduling with 
verification must be supported with response 
times, again, in near real-time. The amount of 
time available for considering schedule 
alternatives is severely limited, especially near 
the end of the countdown. 

The verification and validation issues in our 
software environment, along with the above 
mentioned characteristics led us to approach the 
problem algorithmically, and avoid using 
heuristics. 

While the countdown is formulated in terms of 
both events and intervals, the constraints 
between intervals are such that we have been 
able to represent intervals as start and end pairs 
of events. This has permitted us to restrict our 
representation to a point algebra that along with 
our variation of the Waltz algorithm provides a 
reasoning mechanism that is both sound and 
complete. 

KEY CONCEPTS AND DEFINITIONS 
Time 

From the NTD’s perspective countdown time is 
discrete, with a relatively coarse granularity 
(i.e. the smallest increments are about one 
second). Accordingly, we assume a discrete time 
model and interpret points in time as single 
integer, and intervals as pairs of integers, with 
consecutive integers forming the smallest 
nontrivial intervals. Effectively then, our points 
are “moments- in the sense of (Allen and Hayes, 
1985). A different approach to discrete time 
and “moments- is described in (Schmiedel, 

1990). 

Pseudo Events 

For several purposes TMSA employs events that 
are not members of the universe of countdown 
events employed by the NTDs. As with 


countdown events, pseudo events have integer 
time stamps and generally can be manipulated in 
the same ways as countdown events. Current 
uses of pseudo events are described below in the 
Uncertainty discussion.. 

Uncertainty 

Uncertainty arises in the countdown schedule 
situation in several distinct ways. First of all 
many of the qualitative constraints between 
countdown events are ambiguous (e.g. <*). 
Secondly, ambiguity also occurs in some 
quantitative duration constraints on the length 
of intervals. 

We represent and reason about quantitative 
constraints and uncertainty with the same 
mechanisms used for qualitative constraints and 
uncertainty. For example, to represent that an 
event Ej must occur at or after some point in time 
we generate a pseudo event Ei, time stamp Ei 
with the appropriate time and establish a 
constraint relation Rij of <=. This approach 
extends to duration constraints by using two 
pseudo events, one for the start and one for the 
end. By representing quantitative constraints in 
this way we are able to take advantage of the 
soundness and completeness of the 
ConstraintChecker algorithm. 

In addition to the nominal countdown model and 
constraints, the NTDs also employ a quantitative 
concept of slack time, not unlike that used in 
project planning systems such as PERT or CPM. 

For the NTDs slack time is a valuable resource 
that they seek to preserve for use later in the 
countdown should it be needed. Currently we do 
not explicitly represent or reason about slack 
time, but, we are now examining approaches to 
representing slack time and evaluating the 
quality of schedule alternatives in light of the 
relative preservation of slack each provides. 

Finally, there is the usual uncertainty related to 
confidence in estimates of temporal duration. 
Currently we do not deal with confidence factors, 
but, may in the future, when we begin evaluating 
the quality of schedule alternatives seek some 
measure theoretic approach to confidence. 

Event (Ei): 

A primitive object without discrete time 
duration. Events are used to define the two 
fundamental types of countdown objects. 

Intervals and Milestones, and to uniquely 
represent specific points in discrete time. 
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Universe of Events: 

All the possible events that can occur as part of 
a countdown. These events are specified in 
advance to TMSA or are generated pseudo events, 
and are to be reasoned about by TMSA. 

Interval (Iij): 

A countdown object with temporal duration 
(trivially one) defined by two Events Ei and Ej 
such that if the time stamp associated with Ei is 
<* Ej then Ei is the start of the Interval Iij and Ej 
is the finish. 

Assertions: 

Assertions about Events may be of two types: 
point assertions about a single Event (e.g. Eventi 
occurred at time t); and Relationship Assertions 
about pairs of events (e.g. Eventi o Eventj). 

Quanti tati ve Relati on : 

A temporal duration between two Events that is 
expressed as a natural number corresponding to 
some number of units of discrete time. 

Qualitative Relation: 

One of the following relationships between two 
Events: », <, <*, o, <*> (unconstrained), 0 (null). 
The program converts > to < and >« to <*. 

ALGORITHMS 

Two algorithms have been developed for TMSA. 
These form the reasoning Kernel of the program 
and are designed to monitor and interpret the 
legality of the temporal duration and sequential 
unfolding of a countdown. 

The first algorithm, ConstraintChecker, is used 
to maintain .a qualitative representation of the 
current status of a countdown and to check the 
consistency of that status with the qualitative 
constraints that define the legality of a 
countdown, 

A popular approach in the scheduling literature 
is Allen’s Interval Algebra (Allen, 1983) and 
his adaptation of the widely used Waltz 
Algorithm (Davis, 1987). The ConstraintChecker 
Algorithm is also an adaptation of the Waltz 
Algorithm and employs the Point Temporal 
Algebra presented in (Vilain and Kautz, 1986). 

The ConstraintChecker Algorithm deals only 
with qualitative Relationship Assertions (in the 
form of Relation Vectors). One of the tasks of the 
ScheduleMaintainer Algorithm is to generate 
Relationship Assertions from Point Assertions 
received from the live data stream or the NTDs. 


The second algorithm, ScheduleMaintainer, is 
used to maintain both a qualitative and 
quantitative representation of a countdown, the 
representation includes both the current status 
of the countdown and the quantitative 
constraints that define the legality of a 
countdown. This representation is also used to 
generate relational assertion vectors as input to 
the consistency checking algorithm. 

ConstraintChecker 

ConstraintChecker differs from the Waltz 
algorithm presented in (Vilain and Kautz, 1986) 
in two ways. Our algorithm uses an upper 
diagonal array rather than a n x n array. For our 
problem we needed to maintain not only a 
current representation of the 
constraints/relations between events, but, also 
the original constraints used to define a nominal 
countdown. This permits the algorithm to 
recognize the situation where a change in the 
relation between two events violates the current 
relation, but, not the original one. An 
alternative approach would have been to not 
update the relations vectors, but only check for 
validity of the new assertion. We opted for the 
approach used in order to permit not only the 
checking of new assertions with the original 
constraints, but, also to permit the tracking of 
relation vector changes over time. This 
capability is useful for debugging the constraint 
database. 

We state the following theorems without the 
proofs because of space limitations. 

The time complexity of ConstraintChecker is 

0((ii3)/2). 

The Space Complexity of ConstraintChecker is 
0(n* ). 

The inference mechanism for ConstraintChecker 
is sound. 

The inference mechanism for ConstraintChecker 
is complete. 

ConArray (constraint array) 

An upper diagonal array indexed by events, and 
in which ConArrayfi, j] holds the asserted 
constraint relationship between events i and j. 
ConArray holds the defining qualitative 
constraints (given or generated) that the NTDs 
use to define a legal countdown. Note that 
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unlike EmpArray, ConArray is not updated. 
Thus ConArray maintains a record of the 
original constraint matrix. 

EmpArray (empirical array) 

An upper diagonal array indexed by events, and 
in which EmpAnay[i, j] holds the asserted 
empirical relationship between events i and j. 
EmpArray holds the current, but, changing 
relationships (given or generated) that actually 
occur during the countdown. 

EPQueue (event-pair queue) 

A FIFO data structure used to keep track of 
those Pairs of Events for which a changed 
relationship is asserted. 

The addition operation (+) computes the sum of 
two vectors by finding the common constituent 
simple relations. This is a means to identify the 
least restrictive relationship the two vectors 
together admit. Addition is implemented as a 
Table lookup and is the same as that presented 
in (Vilain and Kautz, 1986). 

The multiplication operation (x) is defined 
between pairs of vectors that relate three Events. 
For example: if Rij relates Events i and j, and Rjk 
relates Events j and k, the product of Rij and Rjk 
is the least restrictive relation between i and k 
that the two vectors together admit. 

Multiplication is also implemented as a table 
lookup and is similar to that presented by 
(Vilain and Kautz, 1986). The table has 
been reorganized to yield valid results using the 
upper diagonal array only. 

ConstraintChecker 

Assert (Rij) 

/* Rij is a relation being asserted between Ei and 

Ej. •/ 

( Tempi j:* Emp Array [ij]; 

EmpArcaypjT:* EmpAnaypj] + Rij; 

If EmpArraypj] ~* Tempij 

Then Put EiEj on EPQueue; } 

Assimilate 

/* Monitors EPQueue for new Relationship 
Assertions */ 

{ While EPQueue is not empty Do 

Get next EiEj from EPQueue; 
Propagate (EmpArraypj]); ) 

Propagate (EmpArray [i j]) 

/* Props new Relation Assertion between Ei and 
Ej to other Events */ 


( For each Event Ek Do 

Tempij:* EmpArray pk] + 
(EmpArraypj] x Emp Array [jk]); 
If Tempij * 0 

Then ( Check 
(Con Array [ij]) ); 

If EmpArraypk] Tempij 

Then Put EiEk on 
EPQueue; 

EmpArraypk]:* Tempij; 

Tempj:* EmpArraypk] + 
(EmpArraypk] x EmpArraypj]); 
If Tempij * () 

Then ( Check 
(ConArray [kj]; 

If EmpArraypk] Tempij 

Then Put EjEk on 
EPQueue; 

EmpArraypk]:* Tempij; } 

Check (ConArraypj]) 

/* Checks to see if new Relation Assertion 
between Ei and Ej, Rij, violates the original 
constraint between them*/ 

{ Tempij:* ConArraypj]; 

ConArraypj]:* ConArraypj] + Rij; 

If ConArraypj] * 0 

Then (signal illegal count); 

If ConArraypj] ~* Tempij 

Then Replace EmpArraypj] with 
ConArraypj] and Put EiEj on 
EPQueue; } 

ScheduleMaintainer 

ScheduleMaintainer generates qualitative 
relational assertion vectors by moving an Event 
data point and time stamp received from an 
external source into the appropriate position on 
the multi-linked list that is the central data 
structure for ScheduleMaintainer. A relational 
assertion vector (Rij) is generated by taking the 
moved Event and its new successor as an Event 
pair EiEj. Quantitative constraints aft 
maintained by using pointers between related 
Events, Ei and Ej for example, and when Ei is 
moved, Ej is moved appropriately, and Eventj is 
then processed as a moved Event, just as the 
original moved Eventi was processed. 

We state the following theorems without the 
proofs because of space limitations. 

The Time Complexity of ScheduleMaintainer is 
O(n). 
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The Space Complexity of ScheduleMaintainer is 
O(n). 

ScheduleMaintainer is initialized by 
constructing an indexed (by External Time) 
multi-linked list data structure (EventList) that 
consists of records corresponding to every Event 
in the Universe of Events. Each of the n records 
(REj) include: 

1. Name of the Event 

2. Marker indicating whether the Event 

has occurred 

3. Time stamp 

4. Marker indicating whether the Time ' 

Stamp is observed, assigned as a 
constraint, or assigned arbitrarily by 
the program 

5. Pointer to Predecessor REi 

6. Pointer to Successor REk 

7. Variable number of nonnull Pointers 

to other REs with quantitative 
constraint relationships between REi 
and the other individual REs 

8. Corresponding quantitative constraint 
for each Pointer 

9. Marker indicating whether the Record 
is to be Moved 

The algorithm receives as input the name of an 
Event and an external time Stamp. The time 
stamp may be when the Event actually occurred 
or assigned by the user (to support interactive 
incremental rescheduling i.e. what-ifing). 

The algorithm then examines the corresponding 
REi to determine if the REi should be moved in 
order to maintain a partially ordered 
(isomorphic) relationship between the discrete 
time of the time stamps of items on EventList and 
the natural numbers. This is done by comparing 
the new discrete time stamp with the time stamp 
of the successor RE. 

If the new External time stamp violates the 
partial order condition, REi is marked to be 
moved and moved to a location that mahitJiMi* 
the partial order condition. 

In the new location, the successor to REi, REj is 
selected and a relation vector for the pair EiEj is 
generated. Depending on the time stamps of the 
two records, the vector is either * or >. If the 
time stamps are equal the vector is *. If the time 
stamps are ordered the vector is >. 

The new relation Rij is then passed to 
ConstraintChecker. 


FUTURE WORK 

C++ is being used for the version currently 
under development. The new version of the 
prototype will provide an exploratory 
function which permits the user to query the 
system about the impact of changes to the 
preplanned countdown schedule. Both of the 
above developments are straightforward and will 
result in improved performance and increased 
functionality, respectively. 

A more challenging task addresses the 
redundancy inherent in an array representation 
of the constraint set. We believe the bandwidth 
(e.g. Zabih, 1990). of the transitive closure of 
the countdown graph is quite small and 
substituting the transitive closure for the 
original graph, will permit us to profitably use 
an adjacency list (e.g. Mehlhom, 1984) rather 
than an array representation of the constraint 
set. We currently believe we can maintain 
inferential soundness and completeness with 
such an approach. The issue seems to be, what 
impact this might have on the scope of the 
models specifiable with such a system. If we are 
able to use this approach, a substantial 
reduction in the time complexity of 
ConstraintChecker is possible. 
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Introduction 

The Job-Shop Scheduling Problem (JSSP) deals with 
the allocation of resources over time to factory oper- 
ations. Allocations are subject to various constraints 
(c.0 M production precedence relationships, factory ca- 
pacity constraints, and limits on the allowable number 
of machine setups) which must be satisfied for a sched- 
ule to be valid. 

The identification of constraint violations and the 
monitoring of constraint threats plays a vital role in 
schedule generation both in terms of (!) directing the 
scheduling process and (ii) informing scheduling de- 
cisions. This paper describes a general mechanism for 
identifying constraint violations and monitoring threats 
to the satisfaction of constraints throughout schedule 
generation. \ A * t \ 

T J .* • 1 * v " ' / 

Identifying constraint violation To achieve a 
valid result in which all constraints are satisfied, a 
scheduler must be capable of distinguishing between 
valid and invalid solutions. This involves, at minimum, 
being able to identify constraint violations in fully- 
generated schedules. Clearly, if the scheduler is only 
able to identify constraint violations in fully-generated 
schedules, backtracking can only be introduced after 
considerable computational effort has already been ex 
pended. To avoid wasted effort, the scheduler should 
be capable of identifying failed states (*.«., states from 
which it will be impossible to achieve a valid solution) 
during the process of generating the schedule. The 
earlier that failed states can be identified, the less un- 
necessary work need be done. 

Monitoring of threats to constraints Given a 
particular factory capacity, constraint violations may 
be identified from the specification of the factory prob- 
lem itself and could lead to a respecification of the 
problem. Alternatively, constraint violations may be 
(inadvertently) introduced by decisions taken by the - 
scheduler. To avoid taking such decisions, potential 
threats to constraint violations may be tracked by a 
lookahead analysis (e.g. % [Liu88, Sad91]). Potential 
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constraint violations occur where the magnitude of the 
estimated demand is close to the available capacity. 
Monitoring constraint threats may be used to direct 
the scheduling process to the most critical constraints 
and inform the decision making process. 

Constraint Monitoring 

Methods of constraint monitoring 
assuming distributions of operation 
demand 

The monitoring of temporal-capacity constraints has 
been a central aspect of a number of scheduling systems 
(t-g-t [Liu88, Sad91, Ber91]). Each of these systems has 
been concerned with estimating demand on resources 
over time to allow comparisons with available capacity 
to be made. 

Although there are important differences between 
the methods adopted for monitoring temporal-capacity 
constraints, the general approach adopted for estimate = 
ing demand is based on assumptions as to the demand 
each operation imposes cm a resource. In the case of 
RESS-II [Liu88], operation demand is assumed to be 
split equally across the valid timewindow of the op- 
eration. In the case of micro-boss [Sad91], opera- 
tion demand is assumed to be split across the valid 
timewindow of the operation on essentially the inverse 
proportion of the cost associated with different start 
times. •' 

Temporal-capacity analysis provides strategic infor- 
mation to the scheduler by highlighting critical re- 
source time periods. This information can then be 
used during schedule generation to choose which par- 
ticular resource time period to address next, to choose 
which operation to allocate and when to allocate the 
operation to effectively redistribute estimated resource 
demand. 

Limitations of making assumptions about 
distributions of operation demapd _ 5 

It is in undertaking an analysis based on splitting op- 
eration demand into a number of separate time periods 
that limitations are introduced in that: 


160 


1. the estimated demand for resource over time in* 
troduces uncertainties associated with assumptions 
made regarding operation demand over time 

2. contiguous time periods are not recognised as being 
contiguous 

For schedulers undertaking an analysis of temporal- 
capacity constraints based on splitting operation de- 
mand over time, capacity bottlenecks indicate regions 
of high resource contention. As a result of the uncer- 
tainties introduced by the assumptions made regarding 
estimated operation demand, it is not possible to tell, 
even where the estimated demand is greater than avail- 
able capacity, whether a capacity constraint has been 
violated or not. This is illustrated in the next section. 

Constraint monitoring in TOSCA 

TOSCa analyses temporal-capacity and setup-capacity 
constraints throughout the &ctory capacity hierarchy 
across multiple time periods. Operation demand is rep- 
resented down to the granularity where the operation 
must legally occur, i.e., the full operation demand is 
associated with the legal time window of the operation. 
The operation demand is not subdivided over the du- 
ration of its legal timewindow, avoiding the need to 
assign probabilities to the possible start times of each 
operation. Normally the operation timewindow is set 
by the release date and due date of the job and the 
intra-lot temporal relationships. Aggregated demand 
can be checked against available capacity both before 
and during schedule generation. 

An example 

Tb distinguish the TOSCA approach, a small example is 
considered using, in the first case, a method based on 
assumptions as to the distribution of operation demand 
and, in the second case, the method adopted in TOSCA 
which avoids such assumptions. The example involves 
the allocation of three operations to a single resource 
which is available for 7 hours per day. For the purpose 
of capacity analysis, the schedule timeline is split into 
periods of 1 day duration. 


Demand: 


Operation 

Duration 

(Hr.) 

Earliest 

Start 

(Day) 

Latest 

End 

(Day) 

opl 

18 hrs 

1 

4 

op2 

3 hra 

2 

5 

op3 

12 hra 

2 

3 


Capacity: 

7 hours per day 

Figure 1: Single resource example 


Method 1: Constraint monitoring 
assuming distributions of operation 
demand 

Constraint monitoring typically involves: 

• maintaining an up-to-date representation of the legal 
timewindow of each operation throughout schedule 
generation 

• splitting the timeline into discrete periods for the 
purpose of analysis 

• for each operation, making assumptions about the 
likelihood of start times across its legal timewindow 

• for each operation, calculating an expected opera- 
tion demand across its legal timewindow 

• aggregating demand for individual resources and 
comparing it against available capacity 

Resource bottleneck periods (i.e., periods where de- 
mand is high relative to available capacity) indicate 
potential threats to capacity constraints and are typi- 
cally used to direct the scheduler to the most critical 
parts of the remaining schedule. 

Methods which split operation demand across the 
operation timewindow assume that each operation ex- 
erts a demand across each of the discrete time peri- 
ods under consideration that fall within the operation’s 
timewindow. For instance opl exerts a demand in peri- 
ods dayl, day2, day3 and day4. Every operation which 
could possibly be active over a particular time period 
contributes to the overall aggregate demand over that 
time period. In this example, the three operations 
(opl, op2, op3) all contribute to the estimated resource 
demand in day2. 

Bottlenecks where estimated demand exceeds avail- 
able capacity cannot be used for the purpose of detect- 
ing constraint violations. Where estimated demand ex- 
ceeds available capacity, it may or may not be possible 
to redistribute demand away from the bottleneck and 
so avoid a constraint violation. 

Figure 2 indicates a distribution of operation de- 
mand based on an assumed uniform probability distri- 
bution of start times. Figure 3 shows the aggregation 
of the demand of these operations, with the horizontal 
dashed line indicating the available capacity. The ver- 
tical dashed lines indicate the granularity of capacity 
analysis. 

Method 2: Constraint monitoring without 
assuming distributions of operation 
demand 

In TOSCA, the demand of an operation is associated 
with its temporal constraints (i.e., its legal timewin- 
dow), without assuming any subdivision of that demand 
across the timewindow. An operation’s demand is as- 
sociated with a single time period. For instance, op2 
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Figure 2: Individual operation demand assuming a un i- 
form operation start time distribution 


exerts a demand of 3 hours over the period [2, 5], no as- 
sumptions being made regarding the probabilistic dis- 
tribution of that demand within that period. 

Only operations which are necessari/p active, given 
that their temporal constraints are to be satisfied, con- 
tribute to the aggregate demand over the time period. 
That is, demand arises from only those operations 
whose legal timewindow are subperiods orthe period 
under consideration. For instance, only the demand of 
opl and op3 are associated with the time period [1,4]; 
the demand of op2 is not included. 

Figure 4 shows the demand over time associated with 
the individual operations, opl has a demand of 18 
hours associated with the period [1, 4], op2 has a de- 
mand of 3 hours associated with the period [2, 5]; and 
op3 has a demand of 12 hours associated with the pe- 
riod [2, 3]. 






Figure 3: Estimated aggregate demand assuming a 
uniform operation start time distribution 



Figure 4: Individual operation demand not assuming 
an operation start time distribution 

In estimating resource demand, temporally overlap- 
ping operations are aggregated. The operations opl 
and op2 together ({opl, op2}) have a demand of 21 
hours over the period [1, 5], {opl, op3} have a demand 
of 30 hours over the period [1, 4], {op2, op3} have 



Aggregate 

demand 



Tine Period [1, 4] 



Hue Period [1,5] 




Figure 5: Aggregate demand not assuming operation 
start time distribution 


a demand of 15 hours over the period [2, 5] and all 
three operations together have a demand of 33 hours 
over the period [1, 5]. Where multiple sets of opera- 
tions are associated with a time period , the demand 
is that of the maximal set of operations. This means 
that the demand on the period [1, 5] is 33 hours, the 
demand associated with {opl, op2, op3} rather than 
{opl, op2}. 

The demand associated with any time period can 
be directly compared with the available capacity — in 
this example, 7 hours per day — to find constraint vi- 
olations and threats. A capacity constraint violation is 
indicated by the demand of {opl, op3}, its demand be- 
ing greater than the maximum available capacity over 
the period [1, 4]. Figure 9 shows the demand asso- 
ciated with the maximal sets of operations associated 
with the periods [1, 4], [2, 3], and [1, 5]. 

In that each timeline period is associated with a set 
of necessary operations - assuming that the operation 
time window constraint holds - the operations impli- 
cated in a constraint violation can be readily identified. 
This can be used to inform constraint relaxations. In 
this example, the timewindow and duration constraints 
of opl and op3 introduce a constraint violation. One 
of their constraints will need to be relaxed to avoid 
this constraint violation. Altering the constraints of 
op2, another operation active over this period, will not 
avoid the violation of the capacity constraint in the 
period [1, 4]. 

Scheduling in TOSCA involves the iterative refine- 
ment of the timewindow of each of the operations. 
Each decision to restrict the timewindow of an opera- 
tion has the effect of redistributing resource demand. 
Before scheduling begins, opl has a demand associated 
with the period [1, 4]. In deciding, for example, to re- 
strict the timewindow of opl to end by the third day at 
the latest, the operation demand becomes associated 
with the period [l, 3]. The effect of these decisions is 
monitored using hahographs . 

Constraint monitoring using 

habographs Habographs (Hierarchical Abstraction 
for Balancing Objectives) are two-dimensional datas- 
tructures used within TOSCA to represent and monitor 
temporal-capacity constraints. Habograph coordinates 
are given as start-end pairs and refer to cells represent- 
ing a time period at a resource. Each operation's earli- 
est start time is plotted on the y axis and its latest end 
time is shown on the x axis. Since it does not make 
any sense to have an earliest start time which is later 
than a latest end time all of the cells above the leading 
diagonal are always empty. The units of the axes are 
problem-dependent. 

In referring to habographs it is important to be clear 
about the use of a couple of terms with respect to infor- 
mation held at a habograph cell: local and aggregate . A 
cell refers to a time period at a resource. Information 
about a resource time period may or may not include 
information about its sub- period. 
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Figures 7 and 9 present an illustration of local and 
®JP*!*te demand in habograpfas on the example de- 
scribed above. 
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Figure 7: Habograph showing local demand 


, Figure 7 indicates the local operations over the pe- 
4J, [2. 5] and [2, 31. opl is local to [1, 4], op2 
is local to (2, 5] and op3 is local to [2, 3]. 
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Figure 8: Aggregate demand 

Figure 9 indicate! the aggregate set of operations 
ewer three time periods. The aggregate set of opera- 
tions includes all the operations which must be pro- 
cessed in a particular period. In the period [1, 4], two 
operations must be processed, these being; opl, which 
must occur between [1, 4] (i.e., dayl through day4), 
and op3, which must occur in the subperiod [2, 3] (i.e., 
day2 through day3). 
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Figure 9: Habograph showing aggregate demand 


The contents of habograph cells Each cell within 
a habograph has a representation of number of objects. 
The main object within each cell is a list of the oper- 
ations which are local to that cell. Each of these op- 
erations exerts a demand for capacity at that cell and 
the sum of the demand exerted by all the cell’s local 
operations is stored as the cell’s local demand. Each 
cell also has an aggregate demand figure, a number cal- 
culated by summing all the local demands in all of the 
cells that are above and to the left of the current cell. 

In addition to the demand associated with a set of 
operations, information is also held as to the capac- 
ity available over the time period represented by the 
cell. As with demand, capacity information is repre- 
sented by a local and an aggregate figure. Local ca- 
pacity is represented only over the leading diagonal of 
the the habograph. In the example under consider- 
ation, the capacity of 7 hours per day is represented 
along the leading diagonal with zero’s everywhere else, 
as is shown in Figure 10. Aggregate capacity shown in 
Figure 11, is calculated in the same manner as the ag- 
gregate demand, described above, except summing the 
local capacity figures rather than the local demand. 

Finally the cell also has a representation for demand 
pressure (Figure 12). This is simply the ratio of the 
aggregate demand at that cell, divided by the aggre- 
gate capacity of that cell. Where the demand 
** trenter than one, a constraint violation is indicated. 
Where the demand pressure is close to but less than 
one, a constraint threat is indicated. In this example, 
a constraint violation is indicated over the period [1, 


Conclusion 

Most current approaches to capacity constraint moni- 
toring involve assumptions regarding the probabilistic 
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Figure 10: Habograph showing local capacity 
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Figure 11: Habograph showing aggregate capacity 
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Figure 12: Habograph showing demand pressure 


distribution of operation start times. Such approaches 
indicate resource bottleneck periods (i.e., periods of 
potential constraint threat) but are unable to identify 
constraint violations. 

This paper describes habograpka, a novel datastruc- 
ture, used for capacity constraint monitoring in to sc a. 
The approach avoids assumptions regarding the prob- 
abilistic distribution of operation start times and has 
the advantage of enabling the identification of resource 
bottleneck periods which necessarily involve a con- 
straint violation. 

Habographs are currently being investigated within 
the TOSCA project as a unifying representation to sup- 
port resource allocation, temporal allocation and setup 
management. 
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Abstract 

This report describes work funded under the 
DARPA Planning and Scheduling Initiative that 
led to the development of SOCAP (System for 
Operations Crisis Action Planning). In particu- 
lar, it describes lessons learned in applying SIPE- 
2, the underlying AI planning technology within 
SOCAP, to the domain of military operations de- 
liberate and crisis action planning. SOCAP was 
demonstrated at the U.S. Central Command and 
at the Pentagon in early 1992. A more detailed re- 
port about the lessons learned is currently being 
prepared [7]. 

This report was presented during one of the panel 
discussions on “The Relevance of Scheduling to AI 
Planning Systems” . 


Introduction 

Many agencies, in addition to the military, have the 
need to manage crises. Good crisis management is 
characterized by quick response, decisive action, and 
flexibility to adapt to the changing situation. Devel- 
oping a good course of action (COA) and modifying it 
as necessary must take into account a number of fac- 
tors: approaches used in past cases that have worked 
well, novel features of the new situation, differing pri- 
orities for subparts of the crisis, and feasibility of sug- 
gested COAs. The objective of this program of applied 
research was to develop decision aids to enable more 
flexible and accurate joint military COAs to be devel- 
oped in response to a crisis. To date, no research or 
development activity has integrated a full-blown gener- 
ative planning system into an operational environment. 

SOCAP (System for Operations Crisis Action Plan- 
ning) embodies SIPE-2, together with a user interface 
tailored to military operations and a situation map dis- 
play system. SIPE-2 (System for Interactive Planning 
and Execution) is a domain-independent, AI planning 
system that was developed during the 1980s by David 
Wilkins of SRI International’s Artificial Intelligence 


Center [4, 5, 6]. It supports both automatic and in- 
teractive generation of hierarchical, partially-ordered 
plans. This system provides efficient methods for rep- 
resenting properties of objects that do not change over 
time, and uses these to constrain the choice of objects 
associated with actions in the plans generated. SIPE-2 
has been tested- out on a variety of small-scale prob- 
lems for travel, robot, and aircraft planning, and for 
extended blocks-world problems. More recently it has 
been applied to a larger scale planning problem in the 
brewery domain. 

In early 1992, SOCAP was demoiutrated both at the 
U.S. Central Command in Tampa, Florida and at the 
Pentagon. The aim was to demonstrate the feasibility 
of applying the SIPE-2 technology within SOCAP for 
the generation of large-scale military operations plans 
(OPLANs). The overall objective is to generate several 
OPLANs that describe employment plans for dealing 
with specific enemy COAs, and identify deployment 
plans for getting the relevant combat forces, support- 
ing forces, and their equipment and supplies to their 
destinations in time for the successful completion of 
their mission. [3] provides a description of the some 
of the requirements for automating the joint military 
operations planning process. 

The rest of this report will describe SOCAP and the 
lessons learned in applying SIPE-2 to the military op- 
erations crisis action planning problem. 

SOCAP — System for Operations Crisis 
Action Planning 

Figure 1 shows the SOCAP architecture, highlighting 
the necessary inputs for the generation of OPLANs, 
the available outputs, and the user interaction. It is 
assumed that the following inputs would be fed into the 
SOCAP database from available military databases: 

• threat assessment - list of enemy threats, locations 
and dates. 

• terrain analysis - information on terrain features 
that might affect mobility and observability. 
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Figure 1: SOCAP Architecture 


• apportioned forces - list of combat forces available 
for planning purposes. 

• transport capabilities - list of available assets. 

Other inputs would come from the user: 

• planning goals — list of goals that match mission 
statement. 

• key assumptions - e.g. rules of engagement, non- 
intervention of third party forces. 

• operational constraints - e.g. overflight privileges, 
troop limits in country. 

In this case, a typical user would be either the mission 
commander or one of his/her joint staff. 

Most of the above information is inherently dynamic 
and is best represented in SIPE-2 as simple first-order 
predicates. However, a great deal of the available data 
are static, and for efficiency reasons are best repre- 
sented in SIPE-2 using its hierarchy of classes and ob- 
jects, together with (static) properties of objects. For 
example, cargo requirements, and combat capabilities 
for specific combat forces should be denoted as (static) 
properties of these forces. 

SOCAP also requires a large set of plan operators to 
describe military operations that can achieve specific 
employment or deployment goals. For instance, there 
are a variety of military operations for deterring an en- 
emy army, navy or air force. Each of these operations 
may be represented by a different plan operator which 
all have the common effect of deterring an enemy force. 
However, they may have different sets of preconditions 
that need to be satisfied before they can be brought 
into the plan, or different resource requirements. 

The SOCAP user interface provides facilities for guid- 
ing the user through the plan generation process. The 


amount of user interaction can be varied during the 
planning process. It can range from being fully auto- 
mated, in which case SOCAP generates a plan with no 
human interaction; to semi-automated, in which the 
user makes some choices; to fully manual, where the 
user makes all the choices. At each goal in the plan, 
the user can request the possible operators that achieve 
the goal to be displayed. Likewise, when attempting 
to bind a variable associated with an argument of an 
operator, the possible bindings can be displayed. For 
instance, the user may be presented with the set of 
military units that have the appropriate capabilities 
to deter an enemy threat, or a list of suitable locations 
for the military operation. This set may be constrained 
by the preconditions and other constraints associated 
with the arguments of the relevant plan operator. At 
the end of each plan level, the plan is checked for log- 
ical consistency, and then progresses to the next level 
until there are no more goals to be satisfied or actions 
to be decomposed further. 

The plan may be displayed at each plan level, either 
as a partially-ordered network of actions and goals, or 
graphically on a time-based map display. The map dis- 
play shows the actions that are occurring on different 
days during the mission. The temporal information for 
the map display is derived from durations associated 
with each action and from the dates when the enemy 
threats should be deterred or countered. 

The following gives an idea of the size and complexity 
of the problems we are dealing with and the knowl- 
edge base within SOCAP. The size of plans we have 
generated have about 100-200 actions in the final plan 
level. The SOCAP, knowledge base comprises: 200-250 
classes/objects, 15-20 properties per object, around 
1200 predicates, and 50-100 plan operators. 

Lessons Learned 

The lessons learned from applying SIPE-2 to the mili- 
tary crisis action planning domain can be divided into 
three main sections: successes and difficulties in apply- 
ing the existing SIPE-2 technology, and open research 
issues. 

Successes 

The hierarchical plan decomposition process embod- 
ied within SIPE-2 maps well onto the military opera- 
tions planning process, and delays the detail until the 
appropriate planning level. As a result, it was rela- 
tively easily to group sets of plan operators according 
to the various phases/levels of the operations planning 
process. For the purposes of the demonstration, these 
were: 

Level 1: Select mission type. 

Level 2: Identify threats and their locations. 



Level 3: Select employment operations, major forces, 
and deployment destinations. 

Level 4: Add deployment actions. 

The class/object hierarchy provides a clear represen- 
tation of static information within SOCAP, and also 
aids validation. A simple constraint language permits 
the properties associated with classes and objects to 
be posted on the arguments of operators. Thus, vari- 
able binding can be delayed until the constraints point 
to a single instance. It is also possible to force instan- 
tiations of these variables with user guidance. For in- 
stance, this facility might be used to force the selection 
of a favored military unit for a specific operation. 

SIPE-2 provides a mechanism for permitting domain- 
specific knowledge to determine the number of itera- 
tions of an operator. For instance, in order to deter- 
mine the number of enemy threats to deter or counter, 
SOCAP checks the number of enemy threat units iden- 
tified in the threat assessment database, and generates 
a sub-goal for each. SOCAP has a variety of itera- 
tive operators that search for different types of enemy 
threats. 

SIPE-2 permits a great deal of information to be pre- 
sented to the user at a variety of levels of detail. The 
SOCAP user interface extracts the appropriate details 
and presents them to the user during the planning pro- 
cess. Thus, when a user is viewing the possible choices 
of military units for an operation, SOCAP presents 
the constraints that led to these choices. Nodes that 
contain certain predicates or arguments may be high- 
lighted on the graphical display. Predecessors, suc- 
cessors and nodes in parallel may also be highlighted. 
This is especially useful when the plan display is large 
and convoluted. 

The time-based map display provides another means 
of displaying the plan that is particularly appealing 
to military planners. It is possible to show the opera- 
tions that occur on each day of the mission and display 
appropriate information about the type of military op- 
eration, the units involved and the boundary of the 
operation. 

Difficulties 


Although SIPE-2 does have capabilities for resource 
reasoning, specifically the representation of reuseable 
and consumable resources, we were unable to make use 
of them effectively, because of the lack of temporal rea- 
soning within SIPE-2. Time windows associated with 
each action involved in a resource conflict would pro- 
vide information that would help to resolve the con- 
flict. Temporal information on the availability of the 
resource would permit simple conflict resolution with- 
out resorting to scheduling. 

Continuing with the temporal reasoning issue, we 


found it would have been very useful to have had 
Allen’s 13 temporal relations [I, 2]. This would have 
permitted more versatile operations including actions 
starting or finishing at the same time, overlapping each 
other, or one occuring during another, as opposed to 
just one strictly before another. There are many exam- 
ples of dependencies between different miltary actions 
that could have been represented, if only... 

Although SIPE-2 does have a mechanism for repre- 
senting shareable resources between actions in paral- 
lel, it is very inflexible, in that you have to determine 
in advance how such resources might be shared over 
several actions. For instance, a large military unit, 
such as a division, may be employed in several opera- 
tions simultaneously, where each operation uses some 
of the division s capabilities. The number of operations 
over which the division may be shared depends on the 
amount of resource required for each operation. Thus, 
the only way to reason about the shared resource is to 
consider the capabilities of the division as a consum- 
able resource purely for this specific set of operations. 

We would have liked to have had a flexible procedure 
for preferring to associate specific resources with ac- 
tions. For instance, when choosing military units for 
operations, in order to minimize the number of troops 
involved in the operation, it is often wise to choose 
units already involved in the plan, provided they have 
not been overutilised. It is possible to write such 
heuristics in SIPE-2, but these are fairly rigid, and 
a trade-off between several heuristics is really what is 
required. 

Another capability we would have liked is the ability 
to combine sub-goals at will, or serendipitously. For 
instance, at present, for every enemy threat identified, 
a friendly unit is identified to deter or counter it. If 
several small enemy forces are located close to each 
other, SOCAP attempts to deal w ith each threat indi- 
vidually, rather than considering them as an aggregate 
threat that might be countered with a single larger 
friendly force. Whether the aggregation was done by 
the user or by some conceptual clustering algorithm, 
it is important that the original sub-goals are replaced 
by a new sub-goal. One could write a large set of plan 
operators that attempt different ways of clustering sub- 
goals, but this is not practical for large problems. 

Currently, it is difficult to represent the notion of a task 
force whose composition is determined by whichever 
military units were assigned to lower level actions. It 
is possible to represent a class of objects of type, task 
force, and make use of a part-of predicate to relate 
specific military units to a specific task force, but this 
is not an easy procedure. 

We could have made greater use of deductive rules 
within SIPE-2 to highlight dependencies between parts 
of the plan that involve long chain * of deduction. 
For instance, the arrival of communications equipment 
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could have triggered deductive rules to fire that would 
have eventually, after several rules, pointed to the 
availability of the necessary command and control fa- 
cilities for another operation. 

It would have been very helpful to have had feedback 
from a “tame” combat simulator. Such feedback could 
have been used to guide the choice of operations, forces, 
locations and times. It could also have been used to 
compare the effectiveness of a variety of courses of ac- 
tions and to provide appropriate metrics for identifying 
qualitatively different CO As. 

Another problem involves SIPE-2*s meta-level control 
of the goal achievement process. Unfortunately, this 
process can only be done by having additional opera- 
tors that copy their goals down to the next level when 
certain preconditions are true. For instance, one may 
decide to achieve all employment goals first and only 
start on the deployment goals when the employment 
goals have been satisfied. This notion of encapsulating 
such meta-level heuristics for goal achievement in the 
preconditions is very rigid. Ideally, one would want a 
more flexible process that permits a trade-off between 
several heuristics. 

As you can gather, we managed to deal with some of 
the above difficulties with less than acceptable solu- 
tions. In most cases these solutions were very rigid and 
might even work well for some problems, but certainly 
would not be flexible enough for a variety of situations. 

Open Research Issues 

We were continually asked by most military operations 
planners to whom we showed SOCAP about support 
facilities for updating and writing new operators. We 
explained that this would involve providing extensive 
facilities for making sure that the preconditions and 
effects were syntactically and semantically correct. It 
would also require flexible test algorithms to ensure 
that the revised or new operators did not adversely 
affect other existing operators. This may provide an 
excellent domain for machine learning techniques. 

There are a whole set of research issues concerning the 
relationship between and integration of planning and 
scheduling techniques. Below, I have just listed a few 
questions below that ought to be addressed: 

• How can information from plan structure guide con- 
straint relaxation? 

• When to stop plan generation and choose to generate 
schedule? 

• When to repair schedule versus plan repair? 

• When to project /simulate the plan/schedule? 


Summary and Conclusions 

The SOCAP work discussed in this report provides the 
first steps towards an operational prototype that will 
eventually be tested out on real military crises. So far, 
it has been tested on a single scenario developed at the 
Armed Forces Staff College. We will be extending the 
system significantly over the next few years, and will 
test it on a variety of different scenarios. You should 
expect a steady stream of progress reports! 
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Abstract 

The Military Airspace Management System 
(MAMS) is a multi-user distributed scheduling 
prototype designed to support the scheduling of 
Special Use Airspace in the CONUS region. The 
prototype has emphasized the user interface de- 
sign of the scheduling system as the primary 
means of producing de- conflicted schedules. This 
paper reports on work in progress and provides a 
technical description of the user interface support 
for the scheduling process. 

1 Introduction 

1-1 Problem Description 

Nearly 25 percent of continental United States (CONUS) 
airspace is designated as Special Use Airspace (SUA) for 
use by the Department of Defense (DOD) for military oper- 
ational readiness training, research and development, and 
lest and evaluation. Demand for this airspace continues 
to increase from both the military and the civil sectors 
resulting in the need for better management. 

There are over 200 military airspace scheduling offices 
of the different services in the United States. In the south- 
west, where the MAMS prototype is being field tested, 
there are at least 20 sites where airspace scheduling is per- 
formed. The military services differ in the schedule infor- 
mation they report on airspaces, and some military areas 
report only scheduled-use, not actual-use data. The ser- 
vices therefore have no uniform source of data to determine 
their actual use, or to compare actual to scheduled use. 

The DOD plans to develop the Military Airspace Man- 
agement System (MAMS) as a solution, automating 
scheduling and reporting of SUA use and providing near 
real-time joint use of airspace. The MAMS prototype is 
being developed to define the requirements for a tool that 
supports efficient scheduling and utilization data collection 
and reporting. 

1.2 History 

Schedulers of SUAs currently have limited automated sup- 
port for scheduling, or simply form a daily flight schedule 
manually. Airspace users phone or fax their requests for 
SUA access to the offices with local scheduling responsi- 
bility. The initial contact is usually followed by a series 
of phone calls. Clarifications are made, and eventually a 
preferred mission time is established. Then, if the local pri- 
ority rules do not interfere, the scheduler of the airspace 
will allow the requested mission to take place. In some 


cases the scheduler can override the local priority rules. 
For example, when a fleet is conducting maneuvers off- 
shore it expects to receive the highest priority, but may 
be overridden if a Top Gun class at the Naval Air Sta- 
tion Miramar needs to fly. There are governing rules for 
airspaces established by the FAA and by letter of agree- 
ment. The DOD rules for assigning priorities in an airspace 
may change from service to service, and sometimes from 
airspace to airspace. The scheduler currently can resolve 
conflicts by generating alternatives, assigning priorities, or 
trying to negotiate a mutually acceptable solution. 

1.3 Prototype Approach . 

The MAMS prototype is planned as a widely distributed 
network of scheduling sites sharing a database of airspace 
resources. The sites will be part of a national military 
airspace management system that preserves their local con- 
trol of resources and provides a hierarchical structure for 
reporting schedule data. The network will allow DOD 
airspace managers to quickly request and schedule mis- 
sions in local airspaces and efficiently request use of remote 
airspaces. 

It was recognized early in user surveys that it would 
be difficult to capture the many scheduling strategies that 
a diverse user community had evolved over time, and to 
establish a consistent set of heuristics that would satisfy 
most users. Many organizations had developed site spe- 
cific policies and procedures for scheduling and managing 
their airspace resources. Scheduling rules and practices 
are therefore very diverse, as a re user in terfaces, and there 
has been some disagreement on a common approach to re- 
solve the differences. Incorporating the daily negotiation 
process in an automated scheduling system would also be 
complicated. ^ 

The approach taken in developing the MAMS prototype 
was to provide an intuitive user interface first, and later 
integrate automated support algorithms. This has had the 
advantage of ptovidinga method lo triuisitron toa more 
automated scheduling system while extracting from the 
users their knowledge of scheduling processes. 

The variety of organizations and their particular 
scheduling strategies has also led us to develop a scheduling 
aid where the user has an explicit role rather than fully au- 
tomating the scheduling system. In an environment of con- 
tinuous dynamic rescheduling it seemed more effective to 
provide the necessary tools via better user interface mech- 
anisms, rather than to incorporate explicit knowledge of 
numerous considerations of the scheduling process. Since 
a given schedule is continuously revised due to changing 
mission requirements, the emphasis on the user interface 
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underscores the role of the scheduler as a problem solver 
rather than a data entry clerk. The effort therefore cen- 
tered on providing useful interface components that facili- 
tate forming and maintaining a schedule regardless of local 
practices or procedures. 

In its technical approach, the MAMS prototype ad- 
dresses the following principal areas: the internal repre- 
sentation of the domain, development and optimization 
of an efficient user interface, supporting analytic routines, 
database and the distributed aspects of the application, 
and data gathering for standardized airspace utilization 
reporting. 


2 Domain Representation 

MAMS uses an object hierarchy to represent Resources 
and Activities. Both resources and activities share a com- 
mon parent, Schedule, that enforces the identification and 
naming of each object in the hierarchy. Domain specific 
types of resources and activities are then specialized by 
inheritance. 

2.1 Resources 

A resource class represents airspace resources. The at- 
tributes associated with the class define the state of the 
resource, which consists of the activities scheduled at the 
resource. All scheduling functionality is embodied in the 
resource object. From this class we specialize two classes 
of airspaces: Special Use Airspaces (SUAs) and Militaiy 
'Draining Routes (MTRs). 

Most SUAs were created as military areas for train- 
ing, testing, and national security. There are six different 
types: Prohibited Areas, Restricted Areas, Military Op- 
erations Areu (MOAs), Warning Areas, Alert Areas, and 
Controlled Firing Areas (CFAs). In 1989 the number of 
SUAs included approximately 350 MOAs, and 120 Warn- 
ing Areas. The airspaces are organized hierarchically and 
are subdivided into further categories designated by the 
organization controlling a particular airspace. 

SUAs can be designated either for exclusive use (only 
one organization may use the airspace), shared use (several 
military organizations may share the airspace), or joint 
use (which allows for simultaneous use of the airspace by 
military personnel and civilians). Airspaces may be also 
dynamically created to support special missions. 

The DOD also uses point to point air routes known as 
Military Training Routes (MTRs). There are four types: 
IRs, which require an Instrument Flight Rules (IFR) flight 
plan, VRs, which require a Visual Flight Rules (VFR) 
flight plan, SRs, designated as special routes primarily for 
slow speed, low altitude operations, and AR routes for air 
refueling. 

2.2 Activities 

An activity is any operation scheduled within an airspace. 
It can be scheduled within any of the resources mentioned 
above, and may contain different domain attributes de- 
pending on the desired resource. In general an activity 
in MAMS is created by a requester, a person desiring the 
SUA. A scheduler must then examine the activity, evalu- 
ate it in the context of the schedule, and act upon it. The 


activity may be edited and changed through the user in- 
terface either by the requester or the scheduler responsible 
for the relevant resource. 

2.3 State 

State describes the most recently completed action on an 
activity. An activity’s state is changed by the requester 
or scheduler through the user interface. A requester may 
create a new activity, delete an existing activity, or modify 
a current activity. A scheduler may look at an activity, 
approve an activity or a conflicting activity, or unschedule, 
deny, or modify an activity. The system also may change 
the state of an activity if a conflict arises. 

The main states of an activity are requests, activities 
which have not been examined by a scheduler, and tasks, 
activities which have been acted upon by a scheduler. 
State is represented in the interface by color coding. Sub- 
mitted requests are shown in blue, when scheduled they 
are changed to green, and if conflicting they are changed 
to red. 

3 User Interface 

In contrast to developing a user interface that provides the 
user with some insight and some control in the automated 
scheduling process [Cooper, 1990], the MAMS prototype 
has approached the problem by first addressing the user 
interface, then ascertaining how more automated support 
could be integrated behind the interface. This section high- 
lights some of the key elements that aid the scheduler in 
establishing a conflict-free schedule. 

3.1 Design Influences 

T he M AMS user interface design is based on previous 
MITRE efforts [Mulvehill, 1986]. It also draws on the 
Range Scheduling Aid [Smith, 1990] , a prototype designed 
to support scheduling of the Air Force Satellite Control 
Network (AFSCN) ground stations and equipment [Smith 
and Katz, 1990; Halbfinger and Smith, 1990]. 

All menus and dialogs in the prototype have been devel- 
oped through extensive interaction with the user commu- 
nity. This feedback has forced many changes, and is the 
source of much of the volatility in the user interface design. 

3.2 Visual Representation 

The user interface is the scheduler’s primary means of es- 
tablishing a de- conflicted schedule. As in many similar 
systems, the interface is modeled on an interactive Gantt 
chart. The main window is divided into horizontal areas, 
or “panes", associated with the resources being scheduled. 
The window is divided from left to right by vertical grid 
lines the user can adjust to represent one hour to one day 
increments. Each requested activity is represented by a 
colored bar icon fixed in height and proportional in length 
to the duration of the mission. Its placement on the screen 
corresponds to the actual time at which the task is due to 
take place. 

3.3 View Control 

The user interface is designed to draw the scheduler's at- 
tention to those areas in the schedule that need repair. At 
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Figure 1: The MAMS Gantt Chart Interface 


startup the interface begins with the current day’s time 
frame so that the scheduler can address immediate requests 
first. 

The interface allows the user to focus on a narrow time 
period, yet gain quick access to distant areas of the sched- 
ule. Using the timeline control at the top of the Gantt 
chart, the user can rapidly view resource data within a 
sliding time interval that can be varied in duration from 
one hour to two weeks. 

3*4 Use of Domain Knowledge 

Airspace resources are naturally organized hierarchically: 
at the top is the controlling organization and in lower 
nodes are sub-areas that are independently scheduled. A 
requester is able to submit a request at any level of the 
resource hierarchy. This action, in effect, is a shorthand 
for requesting all airspaces below the requested node. The 
user may view an airspace at any level in the hierarchy. 
This organization presents an overview of the schedule by 
displaying a summary of resource usage. The prototype 
also supports formation of arbitrary groupings of resources 
to simultaneously schedule at all airspaces of the grouped 
resources. 

3.5 User Conveniences 

To change the time of an activity, the user drags the icon 
horizontally with the mouse. To take other actions, the 
user selects the icon and calls up an appropriate menu. 
The act of selecting an icon prints information about the 
activity in a documentation line along the bottom of the 
screen. 


A find capability helps the user locate a mission of in- 
terest. It displays a list of missions that fit certain search 
criteria, such as requests not yet acted on by the scheduler, 
or conflicting tasks in the scheduler’s airspace. The user 
can then select a mission from the tabular list and have 
the screen reconfigured to the time period of the selected 
item, facilitating the context switch to a new mission. 

The user interface also includes a number of keyboard 
accelerators, error correction on most input fields, an error 
reporting dialog, on-line help, and context sensitive help. 
Co mm ands are supported both through the mouse and 
through key bindings. 

3.6 Multi-User Support 

Unlike previous multi-user scheduling systems [Beard et 
e/., 1990] the MAMS prototype updates user changes in 
near-real-time so that changes made by a requester or 
scheduler will be conveyed immediately to a second sched- 
uler who is working with the same resource for an overlap- 
ping time period. However, MAMS provides the two users 
independent views of the sdiedule at the same time, with 
independent screen layouts and time intervals. 

The interoperability of the X Window System simplified 
development of a multi-user scheduling system by enabling 
the application to open connections to multiple X servers. 
But supporting multiple users introduces additional com- 
plications that need to be addressed in the user interface. 
We added authentication and authorization checking to 
give a user permission appropriate for their role as a re- 
quester or scheduler [Patterson, 1991]. In addition, the 
application needs to support individual user preferences so 
that a user can configure the screen to their liking. 
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4 Analytics 

It may be thought that a ample reservation system might 
liave sufficed, since requests are made and serviced by a 
scheduling authority. However, the scheduler also needs 
support in maintaining temporal and resource constraints. 

4.1 Temporal Relationships 

MAMS maintains a point-based representation of time for 
a single activity, and a symbolic representation of time 
for links between activities. While the prototype does not 
incorporate a temporal constraint engine for maintaining 
temporal relations, it needs to support some temporal re- 
lations. We have found that users need to represent be- 
fore, meets and equal relations [Allen, 1983] for a number 
of situations, but users requested that we represent only 
three relations between activities because other possible 
relations do not have a corresponding use in the applica- 
tion. Temporal relations are used when a complex linked 
mission is being planned, with multiple groups of aircraft 
operating in multiple airspaces according to an interdepen- 
dent sequence of events. The scheduler needs to be able 
to define and maintain these relations. When an activity 
that is part of a linked mission is created, the scheduler 
can establish its dependencies to a concurrent or adjacent 
activity and maintain them graphically in the interface. If 
one activity is moved to a different time the related activ- 
ities move with it. 

4.2 Resource Relationships 

MAMS needs to maintain resource relationships for 
airspaces affected by adjoining airspaces. If, for example, 
an MTR passes through an SUA, scheduling in the MTR 
will also schedule the SUA for the duration of activity in 
the SUA. These kinds of dependencies are automatically 
maintained; the user need not be aware which airspaces 
are related. 

4.3 Conflict Identification 

Currently when conflicts in SUAs are detected for activities 
which overlap in time and altitude within an exclusive use 
airspace, the conflicting activities are highlighted in red. In 
addition, if the airspace is an MTR, conflicts are detected 
if activities are taking place at the same time either at the 
crossing point of two routes or on the same route. This 
would occur, for example, if one airplane were to overtake 
another. Conflict identification is performed each time an 
activity changes state (is either scheduled or moved inter- 
actively). 

4.4 Conflict Resolution 

Thus far, the resolution of conflicts is left to the user. Many 
types of resolutions simply are not possible to automate 
because the system does not explicitly represent all factors 
in a particular scheduling choice. Rather than maintaining 
continuously changing knowledge in the application, the 
scheduler is left to resolve those aspects of the schedule that 
require human judgment, while the prototype maintains 
consistency in the schedule while managing a large set of 
scheduling data. 


4.5 Conflict Description 

The MAMS prototype graphically provides an explanation 
of why two or more activities are considered in conflict 
by wwnfia ting them with connected lines. To aid manual 
resolution of conflicts, the user is then provided with a 
pop-up window containing a scrollable list of conflicting 
missions with conflicting field titles in red. 

The scheduler may choose to accept a conflict, overriding 
the conflict detection. The color of the activity’s icon is 
then changed from all red to green with a red border. 

5 Management 

The schedule, and therefore the airspaces, are managed 
primarily through collection of utilization data. After each 
mission, the participants are expected to report if they flew 
the mission as scheduled, and if not, to report any differ- 
ences. This data is then entered into the system and is 
used to create utilization data reports. The quality of a 
particular mission can be recorded, and if the conditions 
were degraded one can enter the reason. This data can 
then be used to gather statistics about the number of suc- 
cessful missions run in a particular airspace. 

6 Database 

The prototype interfaces to a relational database for long 
term storage and management of schedule data. The 
choice of ^ relatio nal database was deem ed important be- 
cause the system needs to support arbitrary queries on the 
data for report generation. Analysis of utilization data us- 
ing such reports will support long term planning of airspace 
utilization. To maintain a record of multiple users’ actions 
on the data, all transactions are time-stamped so that a 
historical trace of changes can be retrieved. This function 
is considered useful when a scheduler needs to review how 
a particular request was serviced. 

7 Data Dis tribu tion 

One of the primary requirements of the MAMS system, 
from both a DOD and an FAA perspective, has been timely 
dissemination of accurate utilisation statistics. There is 
also a perceived practical and technical need to develop 
a distributed scheduling system. Practically, many site 
surveys showed that few sites would relinquish to an- 
other agency the necessary control to manage their own 
airspaces. This has led to distribution of the application, 
so that each site can continue to manage and control its 
airspaces locally. 

Technically, a distributed approach yields a system that 
is more tolerant of failures. We have experimented with 
the process group paradigm for developing a distributed 
application [Birman et #/., 91; Makpangou and Birman, 
1990]. This has been useful because the programming 
model directly supports the hierarchical structure of the 
DOD command. The hierarchy can be implemented as a 
set of overlapping process groups. 

8 Implementation 

The current prototype n* developed on Sun Microsys- 
tems Sparcst&tion 2s, using C++, the X Window Sys- 



tern, OSF/Motif, ORACLE RDBMS, and bis (a toolkit 
for distributed applications from Cornell University [Bir- 
man et qL, 91]). The C++ object-oriented programming 
paradigm supports our problem domain well. 

The prototype has been evaluated through quarterly 
phased deliveries. Installation of each MAMS phase has 
l>een accompanied by user feedback meetings that were 
an important source of system improvements. Some user 
needs had to be generalized to arrive at a consistent 
scheduling interface. 

9 Further Work 

The Gantt chart has proven to have limitation* a* a uaer 
interface metaphor for representing and resolving non- 
temporal constraints. We are therefore considering adding 
the ability to view the problem space in additional dimen- 
sions. To resolve time and altitude conflicts simultane- 
ously, for example, it would be helpful to the scheduler to 
view a time versus altitude display of a particular airspace. 
We have applied the Gantt chart to linear travel routes, 
such as an MTR, with some success, in that the scheduler 
has enough information to recognise that there is a conflict, 
but there may not be enough to gain an intuitive sense of 
how to resolve a conflict by direct manipulation. We have 
therefore considered displaying an activity that uses MTR 
resources along time and distance axis to better represent 
where a conflict has occurred along a given route. Finally, 
many airspace managers and some users have expressed an 
interest in being able to view the use of airspaces on a map 
in order to better understand the geographic relationships 
of airspace utilisation. This geographic capability would 
also support interactive designation of new airspace parti- 
tions. 

It is recognised that some portions of a schedule are 
repeated weekly or monthly. The users have requested 
the ability to be able to “paste in" a preset template of 
events. To support this feature we plan to provide user 
interface functions to cut a portion of the schedule and 
save it as a template. The user can then select from a list 
of templates and paste the events at a new date in the 
schedule. Invariably users will feel a need to customise 
their environment, and we plan to evolve the application 
to incorporate more user preference selections. We plan to 
run a usability study on the user interface to validate the 
design thus far. 

10 Conclusion 

The MAMS prototype is a proof of concept system, aimed 
at improving the scheduling process within a diverse DOD 
community of schedulers. We found the MAMS schedul- 
ing process complex and difficult to specify completely, and 
thus could not provide a purely automated solution. Our 
approach has therefore been to support the human sched- 
uler with an integrated, easy to use set of took. MAMS 
is an interactive system enabling the scheduler to visualise 
the interdependence of requested activities and to gauge 
the impact of modifying a schedule. The user can thus 
understand the state of a portion of a schedule, and in ere* 
mentally improve it to develop a fair, conflict-free schedule. 

We believe the prototype has helped define the require- 
ments for a future scheduling support system serving a 


large and diverse user community. The emphasis on the 
user interface is believed to be appropriate for scheduling 
problems that have large unstructured domains such as 
MAMS. 
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